4 ms·
When it's an input event in Linux, and you want direct control over what it does, it ultimately ends in writing a daemon with libevdev to get the device event.
by crq-yml 3y ago
When it's an input event in Linux, and you want direct control over what it does, it ultimately ends in writing a daemon with libevdev to get the device event. At least, that is what happened to me last time.
- jraph 3y agoMe too! Following [1]. Maybe worth checking if one is not supported to use libinput instead of processing kernel events directly though. [2] If someone is interested in the input topic, Peter Hutterer's blog is very nice to read. I also enjoyed his talk about libinput's bus factor [3]. [1] https://who-t.blogspot.com/2013/09/libevdev-handling-input-events.html https://who-t.blogspot.com/2013/09/libevdev-handling-input-e... [2] https://who-t.blogspot.com/2018/07/why-its-not-good-idea-to-handle-evdev.html https://who-t.blogspot.com/2018/07/why-its-not-good-idea-to-... [3] https://who-t.blogspot.com/2019/10/libinputs-bus-factor-is-1.html https://who-t.blogspot.com/2019/10/libinputs-bus-factor-is-1...
- kugurerdem 3y agoThese are great references. Read them all briefly, without getting too bogged down in the technical details. As far as I understand it, the libevdev library basically provides one of the lowest levels of interaction with evdev files that comes after reading them yourself, and it is not recommended to read evdev files yourself, as there are many intricacies that can occur.
- RickHull 3y agoHere's a simpler approach; not sure it does what you want; mostly just read / decode / display: https://github.com/rickhull/device_input https://github.com/rickhull/device_input