Ideally we'd cover everything in the C library.

Some of the more important stuff we're currently lacking involves querying device capabilities e.g. driver_version, repeat, the remaining parts of abs_info.

In some cases, we'll need to think carefully about what a pleasant high-level API could look like. Indeed, in some cases, a 1-1 mapping mightn't really make sense (e.g. #10).

posix-paths and filepath-bytestring appear to overlap in functionality. I should probably choose one over the other.

See https://www.reddit.com/r/haskell/comments/e90icy/announcing_the_filepathbytestring_haskell_library/.

If you have Nix installed and run

nix-shell -p haskellPackages.evdev

It should give a message about broken packages.

Package ‘evdev-2.1.0’ in /nix/store/5ahhafra1z3r1acp7n5lcgdyjbfgihj6-nixpkgs/nixpkgs/pkgs/development/haskell-modules/hackage-packages.nix:90322 is marked as broken, refusing to evaluate.
...

If you do

export NIXPKGS_ALLOW_BROKEN=1
nix-shell -p haskellPackages.evdev

It will try to go ahead with the build but will fail on a test

...
Test suite test: RUNNING...
Tests
  Smoke:       FAIL
    Exception: newDevice: does not exist (No such file or directory)
    Use -p '/Smoke/' to rerun this test only.
...

This may not be the correct place to post about such a problem. If so, I apologize, what would be a better place?

I haven't entirely made up my mind on whether to do this, as I had initially intended it to be the main interface.

Some people may care about the fact that it really blows up the dependency graph, e.g. if they wish to use this on embedded systems (does anyone actually use Haskell for that?).

It could be done pretty cleanly.

I knew the day would come eventually, but 1369957 is the first time we've had to worry about this. Obviously, if we had to keep repeating the process used there, we'd quickly get an unmaintainable mess. But it's also total boilerplate, so we should be able to do better.

Could c2hs be patched to allow CPP within enum define blocks (and others?). Currently it causes a "lexical error". Alternatively, maybe it could do something smarter like just not generating the constructor if a constant isn't found. But bear in mind, we would sometimes still want to get warnings.

Otherwise, maybe we should just auto-generate Codes.chs in it's entirety (and drop c2hs?)?

We need to consider what our support policy is. Bear in mind it's mostly just me, and I don't dedicate a lot of time to maintaining this library.

This occurs when there are no devices, at least on my NixOS RPi.

So when it doesn't exist, we should set up an inotify watch for it.

According to document, libevdev_get_uniq and libevdev_get_phys could return NULL. deviceUniq and devicePhys fails with SIGSEGV error when NULL is returned.

Hi, I want to use Haskell to replace a daemon that controls resources through libevdev in a work project. The line of source code above has defaultFlags hard coded into the LowLevel module. Obviously this is a problem when we need to set O_NONBLOCK (as is my need).

I am trying to figure out how to override this library with my local clone in Nix since there is no stack config for this project. I am more than happy to supply a patch for this once I have it building my local copy with Nix. Personally, I would prefer for OpenFileFlags to be an instance of Default from Data.Default. If the EvDev module then re-exported OpenFileFlags as an instance of Default it would provide a simple yet flexible interface for newDevice I think.

Let me know if you would prefer that I approach this differently. I don't want to dictate how your project should be structured ;)

BTW, aside from the O_NONBLOCK problem, this library has worked very well and easily for me. Thank you very much for your effort 😍

python example code & input.c

I'm specifically interested in the Axis and AbsInfo discovery.

(I might add this myself)

I'd really like to support uinput, allowing users to create virtual devices and inject events. There aren't actually many functions needed for a complete API.

We will, however, need to change some existing code. Notably the unidirectional pattern synonyms in the Evdev module are useless now that we'll want to construct events. I think the best way forward is to have a RawEvent type corresponding directly to the C input_event, along with a higher-level Event.

I've tried the usual commands:

sudo groupadd uinput
sudo usermod -a -G uinput $USER
echo 'KERNEL=="uinput", GROUP="uinput", MODE:="0660", OPTIONS+="static_node=uinput"' | sudo tee -a /etc/udev/rules.d/99-uinput.rules > /dev/null

# usually I'd just log out and back in, but that's not an option on Github Actions
# it's possible that not all of these are necessary
# EDIT: related: https://github.com/georgefst/evdev/issues/32
sudo udevadm control --reload-rules
sudo udevadm trigger
sudo modprobe uinput

Checking with ls -l /dev/uinput, the group is correctly set to uinput. But only if there are no uses statements (checkout, cache, setup-haskell) elsewhere in haskell.yml. Somehow these must interfere with the udev rules...

#13 works around this by compiling the test executable, then running it with sudo.

NB: most of this experimentation went on in #12, but the history there is not worth trying to follow

The cabal file says

    base  >= 4.13.0 && < 4.14,

But that release does not exist on hackage yet http://hackage.haskell.org/package/base ?

I would love for the following to work:

git clone [email protected]:georgefst/evdev.git
cd evdev
stack init

Could you publish a release which works like that with stack?

First, thanks for making this library open source!

I'm using it to create a simple background utility to disable my keyboard's and mouse/touchpad devices when needed.
It would be nice if I could use this library to easily enumerate all keyboard and mouse input devices.
For that, I think I need libevdev_has_event_type.

Would you be willing to add this?
If so, I can see if I can create a PR for it (I'm not really familiar with Haskell's FFI, but I can try... ;-)

The evtest executable is useful as a quick way to check that we haven't totally broken everything, but we really ought to have some more extensive tests.

It would be nice to set up continuous integration, especially since hackage-ci is useless for us. Done.

They are genuinely useful.

Even with the lack of polish, I find myself using evtest over the established version.

And trigger would only need slight modifications to absorb scripts like https://github.com/georgefst/xfce-lid-brightness-fix.

Our Github actions setup appears to be re-installing GHC and all Haskell libraries from scratch every time.

I'm not very good with this stuff, but I don't think that was the case when I set it up.

https://www.reddit.com/r/haskell/comments/vivjdo/abstract_filepath_coming_soon

In the Permissions section of the Readme in the evdev folder the following line is given to add a udev rule for permissions to the /dev/uinput device

echo 'KERNEL=="uinput", GROUP="uinput", MODE:="0660", OPTIONS+="static_node=uinput"' | sudo tee -a /etc/udev/rules

Every time I try this it doesn't work. I think its supposed to be

echo 'KERNEL=="uinput", GROUP="uinput", MODE:="0660", OPTIONS+="static_node=uinput"' | sudo tee -a /etc/udev/rules.d/50-uinputRule.rules

which just changes the filename. Well, at least, this is what works for me. To trigger a reload of the rules this seems to work instantly

sudo udevadm control --reload-rules && sudo udevadm trigger

with no relog or reboot necessary assuming you're already a part of the input and uinput groups (which do require relogs) (and maybe(?) assuming the uinput kernel module is loaded) which makes testing easier.

Hello! I noticed that this project does not compile on GHC versions newer than GHC 9.4 . This is what happens with 9.6.5:

$ cabal build --minimize-conflict-set evdev
Resolving dependencies...
Error: cabal: Could not resolve dependencies:
[__0] trying: evdev-streamly-0.0.2.0 (user goal)
[__1] next goal: streamly (dependency of evdev-streamly)
[__1] rejecting: streamly-0.10.1 (conflict: evdev-streamly => streamly^>=0.9)
[__1] skipping: streamly-0.10.0 (has the same characteristics that caused the
previous version to fail: excluded by constraint '^>=0.9' from
'evdev-streamly')
[__1] trying: streamly-0.9.0
[__2] next goal: streamly-core (dependency of streamly)
[__2] rejecting: streamly-core-0.2.2 (conflict: streamly =>
streamly-core==0.1.0)
[__2] skipping: streamly-core-0.2.1, streamly-core-0.2.0 (has the same
characteristics that caused the previous version to fail: excluded by
constraint '==0.1.0' from 'streamly')
[__2] trying: streamly-core-0.1.0
[__3] next goal: base (dependency of evdev-streamly)
[__3] rejecting: base-4.18.2.1/installed-4.18.2.1 (conflict: streamly-core =>
ghc-prim>=0.5.3 && <0.10, base => ghc-prim==0.10.0/installed-0.10.0)
[__3] rejecting: base-4.20.0.1, base-4.20.0.0, base-4.19.1.0, base-4.19.0.0,
base-4.18.2.1, base-4.18.2.0, base-4.18.1.0, base-4.18.0.0, base-4.17.2.1,
base-4.17.2.0, base-4.17.1.0, base-4.17.0.0, base-4.16.4.0, base-4.16.3.0,
base-4.16.2.0, base-4.16.1.0, base-4.16.0.0, base-4.15.1.0, base-4.15.0.0,
base-4.14.3.0, base-4.14.2.0, base-4.14.1.0, base-4.14.0.0, base-4.13.0.0,
base-4.12.0.0, base-4.11.1.0, base-4.11.0.0, base-4.10.1.0, base-4.10.0.0,
base-4.9.1.0, base-4.9.0.0, base-4.8.2.0, base-4.8.1.0, base-4.8.0.0,
base-4.7.0.2, base-4.7.0.1, base-4.7.0.0, base-4.6.0.1, base-4.6.0.0,
base-4.5.1.0, base-4.5.0.0, base-4.4.1.0, base-4.4.0.0, base-4.3.1.0,
base-4.3.0.0, base-4.2.0.2, base-4.2.0.1, base-4.2.0.0, base-4.1.0.0,
base-4.0.0.0, base-3.0.3.2, base-3.0.3.1 (constraint from non-upgradeable
package requires installed instance)
[__3] fail (backjumping, conflict set: base, evdev-streamly, streamly-core)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: base, streamly, evdev-streamly,
streamly-core

But simply allowing a newer version of streamly seems to fix the issue:

$ cabal build --allow-newer="evdev-streamly:evdev" evdev
Resolving dependencies...
Build profile: -w ghc-9.6.5 -O1
In order, the following will be built (use -v for more details):
 - evdev-2.3.1.1 (lib) (first run)
Configuring library for evdev-2.3.1.1..
Preprocessing library for evdev-2.3.1.1..
Building library for evdev-2.3.1.1..

In this case, cabal could compile it fine with streamly-0.10.1. Could we bump this dependency to support GHC 9.6? I ran the evdev:test suite without issues and evtest also seems to work after the update.

I get the following error, when trying to use evdev-streamly on nixpkgs unstable (same on nixpkgs 22.05/22.11/23.05):

nix shell unstable\#haskellPackages.evdev-streamly --impure
error: builder for '/nix/store/lssfyyhr322w39rjrbafs4f91jsh7c19-evdev-streamly-0.0.2.0.drv' failed with exit code 1;
       last 10 log lines:
       > [1 of 1] Compiling Main             ( /nix/store/4mdp8nhyfddh7bllbi7xszz7k9955n79-Setup.hs, /build/tmp.dstfp9A7qI/Main.o )
       > Linking Setup ...
       > configuring
       > configureFlags: --verbose --prefix=/nix/store/jg6q7lvlfz1bk50h2p71a366zfdyqhq4-evdev-streamly-0.0.2.0 --libdir=$prefix/lib/$compiler --libsubdir=$abi/$libname --docdir=/nix/store/flz5h9yma67iask39akiqg41vgn9a0ch-evdev-streamly-0.0.2.0-doc/share/doc/evdev-streamly-0.0.2.0 --with-gcc=gcc --package-db=/build/tmp.dstfp9A7qI/package.conf.d --ghc-options=-j16 +RTS -A64M -RTS --disable-split-objs --enable-library-profiling --profiling-detail=exported-functions --disable-profiling --enable-shared --disable-coverage --enable-static --disable-executable-dynamic --enable-tests --disable-benchmarks --enable-library-vanilla --disable-library-for-ghci --ghc-option=-split-sections --ghc-options=-haddock --extra-lib-dirs=/nix/store/lqp3skf8jpvs6v7s6libhzg5450drkcc-ncurses-6.4/lib --extra-lib-dirs=/nix/store/vx3w08jclifb4smnkf6ypjfsvrhnrlg8-libffi-3.4.4/lib --extra-lib-dirs=/nix/store/h2pqqpgkfjh0q3rf9ya44p8swmiwa4bs-gmp-with-cxx-6.2.1/lib
       > Using Parsec parser
       > Configuring evdev-streamly-0.0.2.0...
       >
       > Setup: Encountered missing or private dependencies:
       > evdev >=2.1 && <2.2
       >
       For full logs, run 'nix log /nix/store/lssfyyhr322w39rjrbafs4f91jsh7c19-evdev-streamly-0.0.2.0.drv'.

Seems haskellPackages.evdev is only available for version 2.2, which clashes with the versions specified in evdev-streamly.

nixpkgs-unstable version as found in flake.lock:

"unstable": {
      "locked": {
        "lastModified": 1679437018,
        "narHash": "sha256-vOuiDPLHSEo/7NkiWtxpHpHgoXoNmrm+wkXZ6a072Fc=",
        "owner": "NixOS",
        "repo": "nixpkgs",
        "rev": "19cf008bb18e47b6e3b4e16e32a9a4bdd4b45f7e",
        "type": "github"
      },
      "original": {
        "owner": "NixOS",
        "ref": "nixos-unstable",
        "repo": "nixpkgs",
        "type": "github"
      }
    }