libinput varlink implementation?

[Markus Ongyerth]

On 2018/5月/11 10:12, Peter Hutterer wrote:
> 
> > Never the less, a few pointers to the varlink approach from my side:
> > From your quick outline in the mail, I asume you plan to have the varlink fd 
> > libinput owned? I don't think that fits the current scope of libinput (or that 
> > it's a good idea). If it can be integrated into a general connection of the 
> > compositor, that would be better.
> 
> In the current implementation, which took a grand total of an hour to write,
> I let libvarlink open the fd (hoever it does that, I haven't checked the
> sources) and then add the fd to libinput's epoll fd. So you call
> libinput_dispatch() just like you currently do - without knowing what
> triggered the data.

I only took a quick look at the varlink documentation, but from what I 
understood it should be possible to add a libinput debug interface to a 
varlink context opened and used by the compositor.
Provided varlink is used more in the future, that would IMO be preferable to 
providing multiple varlink sockets from the same process.

> 
> > Another thing I'd like to see (maybe even more? honestly not sure) would be a 
> > mode to just take a stream/memory-buffer from the application and pass back 
> > memory-buffers to it for communication, this may require some support from the 
> > library, but it would allow compositors to integrate the functionality into 
> > whatever IPC they provide.
> 
> uh, that sounds to me like you're trying to do IPC to hook up IPC? :)
Mhh, the idea was to consider varlink a plaintext (or opaque, idc) protocol 
that could be transported over any IPC mechanism, and just hook it into an 
already existing method.

But thinking about it, all you need is a dump, right? Would it be enough to 
have a function that simply writes a dump (or provides it in memory) that just 
has to be called?

Getting the right socket in a situation with two of the same instances of the 
application running on different ttys in a generic way could be hard, so maybe 
it's better to get it over some specific interface?

Personally I'd still prefer the wayland protocol, but I get that it's not the 
only place where libinput could be used and might not be what you want.

> 
> > It would make the dumping tool a little compositor specific though, so it may 
> > be an anti-goal.
> 
> yeah, definitely, anything that's compositor specific is a non-starter.
> Too much work and ETIME. Plus the issues with having to write documentation
> for "how to I debug this on $FOO".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180514/95c44f0d/attachment.sig>