libinput varlink implementation?

[Peter Hutterer]

On Mon, May 14, 2018 at 07:51:33AM +0200, Markus Ongyerth wrote:
> 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.

yeah, true. It would require the VarlinkService handle be passed to libinput
but otherwise this should work. It moves the onus of establishing that
service to the compositor though, as opposed to keeping it contained within
libinput. But it is nicer, no question about that.

Also moves the processing into a callback outside of libinput_dispatch() but
I don't think that would be a problem.

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

any dump needs a file format and parsing. I'm not planning to do the
synaptics-style SHM again. And once we have a file format and parsing, we
either do it by hand or use json/yaml/xml which then again require a parser.
maybe not for writing (see libinput-record, but the only reason I didn't use
one there is because I couldn't find one that gave me continuous data
writes).
 
> 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?

I'm not sure if the varlink sockets are part of the ABI. fd-passing isn't a
thing so the best we could do there is pass a "/run/...." path through the
known interface and then assume that's a valid varlink path.

but unless I'm mistaken - this is only moving the problem, if you have two
instances of the same application running (e.g. mutter), you still need to
figure out which one to call to get the right socket to then get to libinput.
so something is definitely needed here, I just don't know what...

Cheers,
   Peter

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