libinput varlink implementation?

[Peter Hutterer]

On Thu, May 10, 2018 at 08:23:31AM -0400, Drew DeVault wrote:
> Can you be more specific about your use-case? As far as I can tell, you
> want to find out how the devices were configured by the compositor. On
> sway this is as straightforward as reading sway's debug log.
> 
> I guess I'm not clear on why a more complex solution is necessary.

Basically: I want some generic tool that's tied to libinput to tell me about
the state of devices in the compositor context.

The wayland protocol abstracts input enough (rightly so) that I can't tell
which devices are actually in use. And the context is abstracted enough that
I can't tell which configuration options are applied. For compositors that
have options that should apply per-touchpad or per-trackstick, this matters
because I can't verify whether an option is applied. for example, if tapping
doesn't work this could be because mutter never applied the option to a
specific device (misdetection of a touchpad, etc.) or because of a libinput
bug.

With X all devices are exposed as separate devices, and their configuration
options are the properties. xinput list and xinput list-props give me the
state of the devices to a resonable approximation (the xf86-input-libinput
driver is a thin wrapper so this corresponds basically 1:1 to the libinput
state). This is useful for debugging.

I may get that information from the compositor log, but then I'm relying on
a) that the log files stay the same and b) that the compositor really logs
everything and c) that every compositor does that. but I won't be able to
automate this because I doubt you guys will all agree on one log file
format :) Reading debug logs is actually a lot more complex than having
a machine-readable format. AIUI, that is one of varlink's core motivations.

The varlink implementation [1] means I can write that tool as part of
libinput, it'll be tied to the libinput implementation and not lag behind.
I can get options out of libinput even without the compositor supporting
that particular option, you can update libinput without the compositor and
the tool remains in step. That's a real issue too,  When debian/ubuntu
didn't update evemu for 2 or 3 years, we had to ask every single bug
reporter for extra files and info, wasting time and developer bandwidth.
(avoiding this situation was one motivation for the libinput
record/replay tools)

So yeah, the whole thing is for *me* and to improve debugging of the running
libinput context. It's the easiest way to add this without putting any extra
development efforts on the compositor authors who are just as busy with
their stuff.

Hope that clarifies things, happy to explain more in detail where needed

Cheers,
   Peter

[1] or any other IPC implementation, but varlink is just the easiest so far