libinput varlink implementation?
peter.hutterer at who-t.net
Sun May 13 07:31:30 UTC 2018
On 13/5/18 01:04 , Pekka Paalanen wrote:
> On Thu, 10 May 2018 10:10:10 +0200
> Markus Ongyerth <wl at ongy.net> wrote:
>> 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
> FYI, there is no need for a compositor to proxy or implement stuff
> on behalf of libinput. The whole Wayland extension implementation
> can be inside libinput, enabled with a single function call that
> passes the server-side wl_display to libinput. This is how libEGL
> implementations provide vendor-specific Wayland extensions while
> keeping compositors completely agnostic of any details.
thanks, I didn't know about that. Having a wayland protocol would make
the whole thing wayland-specific though. Even though it's likely the 95%
use-case (outside of xorg obviously), that could be a limiting factor.
> A small hurdle is what to do about libinput needing to call
> libwayland-server in that case.
> This is not a vote for or against using a Wayland extension for
> specifically this case. I just wanted to point out that there is no
> need to require any more than few lines of code in compositors to
> opt in.
> Personally, I don't think I would mind what the underlying protocol
> to debug libinput is, as long as it is a simple matter for a
> compositor to opt in, and read-only.
More information about the wayland-devel