libinput varlink implementation?

Fri May 11 00:12:14 UTC 2018

So we don't cross the streams, some motivation is in the reply to Drew,
https://lists.freedesktop.org/archives/wayland-devel/2018-May/038148.html
I'll try to avoid duplication of those points here.

On Thu, May 10, 2018 at 10:10:10AM +0200, Markus Ongyerth wrote:
> A quick glance at varlink makes me like it more than dbus, but I'm not sure 
> it's the best choice to provide debug information about libinput configuration 
> in compositors.
> 
> All compositors I'm aware of, provide an IPC method for some (more or less) 
> internals. GNOME (and afaik KDE) have dbus, sway has the i3-ipc protocol, 
> waymonad provides a FUSE filesystem.
> They also all speak wayland (duh) and there may be more I'm not aware of 
> (pipewire?).
> Adding varlink would be, at least the 3rd generic IPC mechanism (after 
> wayland/dbus/custom) that the compositors provide. IFF we can expect varlink 
> to replace dbus for the environment I'd welcome it, but at the current time 
> I'd rather not introduce another generic IPC library/mechanism.

fwiw, the intention was to have the implementation provided by libinput,
with the compositor just making the call whether it should be exposed or
not.

> I'd also prefer to have a generic configuration interface in the future, which 
> IMO would be best to be based on a read-only introspection method.  And I 
> think we got the best chances to provide decent UX for querying the user for 
> permission if we use wayland extension protocols. 

I think we talked about this a few years back and the problem with the
generic configuration interface is that you have two options:
a) map libinput's config interface to a wayland protocol
b) fail (because no-one can agree on what configuration options are
applicable)

It's one of those problems that sound incredibly simple until you start
working on it. And the problem isn't technical, the problem is that you need
to make decision on what not to include and everyone has to agree with you
on that. Good luck with that :)

Oh, and while libinput is the de-facto input stack there are still a few
use-cases where it's not being used, so you don't get a generic
configuration interface, you get a libinput configuration interface.

> Partially because we already have a need to secure them, and this could be 
> plugged into that method, and because this provides a strong coupling of 
> windows of a client to requests it makes (over the wl-client).
> This would allow us to show a UAC like query that shows the client in question 
> (via its windows) and what protocol is to be accessed.
> If any other IPC method is used, we lose this strong, unique association.

I'm not sure of the need to secure them (at least not beyond an on/off
toggle). This is a debugging interface and I have no plans to add events or
calls to change configuration. It's the equivalent of running xinput list or
xinput list-props. It's harmless, IMO

> For the reasons stated above, I think we would be better suited with an 
> interface defined as wayland extension. The downside is, that it has to be 
> proxied and implemented by the compositor, but I think the advantages outweigh 
> this.

As stated in the other email, I really want this to be tied to libinput so I
don't have to wait for a distro to update the compositor to debug issues
with a newer libinput. Once bitten, twice shy :)

> Never the less, a few pointers to the varlink approach from my side:
> From your quick outline in the mail, I asume you plan to have the varlink fd 
> libinput owned? I don't think that fits the current scope of libinput (or that 
> it's a good idea). If it can be integrated into a general connection of the 
> compositor, that would be better.

In the current implementation, which took a grand total of an hour to write,
I let libvarlink open the fd (hoever it does that, I haven't checked the
sources) and then add the fd to libinput's epoll fd. So you call
libinput_dispatch() just like you currently do - without knowing what
triggered the data.

> Another thing I'd like to see (maybe even more? honestly not sure) would be a 
> mode to just take a stream/memory-buffer from the application and pass back 
> memory-buffers to it for communication, this may require some support from the 
> library, but it would allow compositors to integrate the functionality into 
> whatever IPC they provide.

uh, that sounds to me like you're trying to do IPC to hook up IPC? :)

> It would make the dumping tool a little compositor specific though, so it may 
> be an anti-goal.

yeah, definitely, anything that's compositor specific is a non-starter.
Too much work and ETIME. Plus the issues with having to write documentation
for "how to I debug this on $FOO".

Cheers,
   Peter

> Cheers,
> ongy
> 
> P.S. I'm aware that some people claim that the security issue can be solved 
> with the portal/dbus/container combination.
> a) I don't like the though of running everything in a container (yet)
> b) We can apply the same (or IMO even better) filters over wayland sockets
> 
> On 2018/May/10 03:07, 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...
> > 
> > Cheers,
> >    Peter
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel