libinput varlink implementation?

Pekka Paalanen ppaalanen at gmail.com
Sat May 12 15:04:32 UTC 2018


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

Hi,

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.

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.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180512/b7ec95f5/attachment.sig>


More information about the wayland-devel mailing list