evtest and libevdev

Peter Hutterer peter.hutterer at who-t.net
Wed May 19 22:38:10 UTC 2021


On Wed, May 19, 2021 at 10:58:18PM +0200, Thomas Weißschuh wrote:
> Hi everybody,
> 
> while playing with Linux input subsystem I stumbled up the fact that evtest does
> not use libevdev.
> This became apparent as that evtest was not able to resolve the string name of
> a keycode (KEY_MACRO1) which however was known to libevdev.
> 
> This was surprising as just before I read the following snippet in libevdev.h:
> 
> /*
>  * libevdev is essentially a `read(2)` on steroids for `/dev/input/eventX`
>  * devices. It sits below the process that handles input events, in between
>  * the kernel and that process. In the simplest case, e.g. an evtest-like tool
>  * the stack would look like this:
>  *
>  *      kernel → libevdev → evtest
>  */
> 
> Are there non-obvious reasons for evtest not using the functionality from libevdev?
> (Especially the update-heavy name resolution)

yes, there are and that documentation is not correct, or not correct
enough :)

evtest is intended to be the most minimal debugging tool so you can just
wget && gcc it on any machine without requiring extra dependencies. So it
will never depend on libevdev.

evtest's output is not easily machine readable either, so at this point I
recommend using libinput record instead, which truly is like this:
   kernel → libevdev → libinput record
same functionality as evdev but it spits out yaml which can then be parsed
and analyzed easily.

Cheers,
   Peter


More information about the Input-tools mailing list