libinput varlink implementation?
wl at ongy.net
Mon May 14 05:51:33 UTC 2018
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...
Size: 833 bytes
Desc: not available
More information about the wayland-devel