libinput varlink implementation?

[Peter Hutterer]

restoring the CC list, because thunderbird...

On Sun, May 13, 2018 at 10:19:34AM -0400, Drew DeVault wrote:
> On 2018-05-13  5:35 PM, Peter Hutterer wrote:
> > On 11/5/18 21:38 , Drew DeVault wrote:
> > > Maybe `ltrace --library=libinput.so ./run-compositor` would be
> > > sufficient?
> > 
> > Maybe, but that's a *lot* more inconvenient for quick debugging than any IPC
> > mechanism. I admit I haven't used ltrace but strace does throw up heisenbugs
> > every once in a while because timings are different, etc. I'd rather avoid
> > that.
> 
> I'd suggest trying that before adding a new dependency, protocol, and
> bunch of maintenance burden to libinput.

ltrace requires me to start whatever it is to be debugged through ltrace.
That is basically a non-starter for 90% of the users I'm dealing with. I'm
struggling to get users to run commands that explicitly tell them what to do
next or even follow basic documentation in the form of "run this command,
look at the output, think".

I think the maintenance burden of any IPC protocol is less than having to
explain to users how to ltrace a gdm session if they don't even know how to
compile (or follow instructions on how to compile). libinput's architecture
being how it is, one solution to work OOTB rather than millions of knobs,
means I cannot just tell the users to bugger off. They have the hardware I
don't have access to, they need to provide the logs to fix it otherwise we
may have a whole series of laptops not working.

Cheers,
   Peter