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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
