On Sun, May 13, 2018 at 05:31:30PM +1000, Peter Hutterer wrote: > On 13/5/18 01:04 , Pekka Paalanen wrote: > > 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. > > 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.
It'd also make it more complicated to sandbox, would that matter, as the compositor would have to actively have per-sandbox-type detection and filtering. Jonas > > Cheers, > Peter > > > > > > 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 > > > _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
