evtest and libevdev

[Thomas Weißschuh]

Hi Peter,

On Do, 2021-05-20T08:38+1000, Peter Hutterer wrote:
> 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.

Thanks for the info!

Thomas