libinput varlink implementation?

[Jonas Ådahl]

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