libinput varlink implementation?

[Jonas Ådahl]

On Thu, May 10, 2018 at 03:07:36PM +1000, Peter Hutterer wrote:
> one of the issues we have with libinput in the wayland world is that
> debugging it is a bit harder than in X. There we can just run xinput
> list-props and get an idea of what settings are applied to each device which
> helps narrow down where the issue really is. Under Wayland, that is not
> available, for all the obvious reasons.
> 
> Last year Carlos and I had a chat about this and thought about maybe
> exposing the devices via DBus from mutter. This way we could at least have
> some generic tool dumping state for debugging. This was not intended as a
> configuration interface. I never got to write those patches, but I vaguely
> remember KDE having something like this already, Martin could probably
> commment more here.
> 
> Recently, varlink is a bit in the news (http://varlink.org) and it is simple
> enough. and tempting... The current (very early) thought is to have
> something in the form of:
> 
>     libinput_varlink_init_service(libinput, "compositor-name")
> 
> which sets everything up as part of libinput's epoll. It then allows for
> this:
> 
> varlink call unix:@libinput-mutter.socket/org.freedesktop.libinput.Devices
> {
>   "devices": [
>     "event2",
>     "event5",
>     "event0",
>     "event1",
>     [...]
>   ]
> }
> 
> Followed by more detailed calls.
> 
> The bit above works locally, it's around 100 LOC. Easy enough to extend
> with device information and configuration options. But there are many
> details to be sorted, amongs them the name of the socket (we may have
> multiple libinput instances running). It's obviously a backchannel around
> the compositor which is why I intend to only give it read-only access.
> 
> From libinput's POV this would allow for a generic "libinput inspect" tool
> (or something like that) to query the actual libinput context used.
> Again, not with write access, but to query which devices are available, what
> configuration options are set, etc. This would help for debugging but
> varlink is not something I would generally expose without the compositor's
> permission. Which means I need a 'yep' from at least some of you (and those
> I forgot to add to the CC :)
> 
> Thoughts? Obviously varlink is still in its very early stages and there's no
> guarantee of adoption, etc. But I'm somewhat optimistic about it, given how
> simple it is to add support for it to anything. Harald, Kay and Lars are in
> the CC as well, to tell me off it this is explicitly not what varlink is
> supposed to do...

While D-Bus would be just as fine (it could for example be an interface
on some name a compositor already owns), varlink seems like a pretty
good fit for input device configuration introspection. Using a separate
unix socket it seems fairly easy to sandbox too, I expect.

Does varlink allow this to be easily discoverable without knowing what
"compositor-name" is being used (or any other "unique name")?

If anything was unclear here, you can file me under the "Yep" column.


Jonas


> 
> Cheers,
>    Peter