libinput varlink implementation?

Thu May 10 08:10:10 UTC 2018

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.

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. 
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.

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.

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.

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.
It would make the dumping tool a little compositor specific though, so it may 
be an anti-goal.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180510/c82f4571/attachment.sig>