On Thu, 10 May 2018 10:10:10 +0200 Markus Ongyerth <w...@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
pgpyMrKAWpuLb.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
