[RFC libevdev] Enable event logging for debugging

Peter Hutterer peter.hutterer at who-t.net
Fri Apr 4 20:46:43 PDT 2014


On 5/04/2014 05:32 , David Herrmann wrote:
> Hi
>
> On Thu, Apr 3, 2014 at 11:33 PM, Peter Hutterer
> <peter.hutterer at who-t.net> wrote:
>> I see a couple of issues here: one is that libevdev has _no_ connection to
>> systemd at all. it doesn't even use udev and I like to keep it simple that
>> way. which is why the minor number is currently required instead of the
>> device node. so that makes filtering on the device node hard to begin with
>> (we could guess the node with a loop through /dev/input though)
>
> Ugh, you guys misunderstood me. I was in no way implying a relation to
> systemd, "journalctl" was just a way to filter messages. I could have
> said "tee evdev.log | grep STH" instead. I just thought people are
> more familiar with journald-style KEY/VALUE filtering. Anyhow, all I
> was saying is that I'm fine with libevdev-internal filtering, as long
> as "log everything with a node/dev_t attribute" stays supported. The
> important thing here is the proper attribution, though.
>
>> that is exactly the point of this patch. logging every event from every
>> device at all times is a large amount of data, especially with touchpads,
>> touchscreens or graphics tablets. And in 99% of the use-cases that data is
>> just wasting space and isn't used.
>
> Imho, logging is cheap and 1% of useful data is still a reasonable
> amount, but I don't mind if others disagree.

data logged by libevdev is nowhere near 1% usefulness. Think about it, 
every input event you've generated over the last year and how many of 
those you'll actually care about? It's hard enough to get 1% usefulness 
when you ask users to reproduce a specific bug...

Cheers,
   Peter

>> The real use of this is to be able to get sequences for _bugs_ without
>> having to tell users to apply a patch from here and then another patch from
>> there. Hence the environment variable, it's easy to set, no recompilation is
>> needed but the data still goes to the same log as before.
>
> Env-vars are perfect for that! Please go ahead.
>
> Cheers
> David
>



More information about the Input-tools mailing list