See Hackage for documentation on the core library and the streamly add-on.
The evdev-examples folder contains a basic evtest
clone, with the added ability to read events from multiple devices concurrently.
Haskell bindings to libevdev. Read from Linux input devices, and create virtual ones.
Home Page: https://hackage.haskell.org/package/evdev
See Hackage for documentation on the core library and the streamly add-on.
The evdev-examples folder contains a basic evtest
clone, with the added ability to read events from multiple devices concurrently.
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.
evdev/evdev/src/Evdev/LowLevel.chs
Line 86 in a3959e5
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 😍
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 Done.hackage-ci
is useless for us.
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.
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"
}
}
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.