[RFC libevdev] Enable event logging for debugging

Jonas Ådahl jadahl at gmail.com
Thu Apr 3 08:03:35 PDT 2014


On Thu, Apr 03, 2014 at 10:30:44AM -0400, Benjamin Tissoires wrote:
> On Thu, Apr 3, 2014 at 10:00 AM, David Herrmann <dh.herrmann at gmail.com> wrote:
> > Hi
> >
> > On Thu, Apr 3, 2014 at 12:30 PM, Peter Hutterer
> > <peter.hutterer at who-t.net> wrote:
> >> This is a new approach to an earlier patch [1]. I'm running into more
> >> use-cases where I really need the event sequence the caller sees to figure
> >> out where the bug is. Note that the patch is just lightly tested, this is an
> >> early RFC.
> >>
> >> I'll just copy the documentation here, that explains what I'm trying to do:
> >>
> >> + * libevdev checks the LIBEVDEV_LOG_EVENTS environment variable. If set to
> >> + * "error", "info", or "debug", all events are logged with the respective
> >> + * priority before they are passed to the client. This is useful to check
> >> + * event sequences that happen before a specific bug in the higher layers of
> >> + * the stack
> >> + *
> >> + * To debug specific devices only, the minor numbers of the device node may
> >> + * be provided as a comma-separated list after the priority:
> >> + * LIBEVDEV_LOG_EVENTS="error:1,2,3" logs all events from the devices with a
> >> + * minor number 1, 2 or 3. The minor number comparison is performed on
> >> + * libevdev_set_fd() and libevdev_change_fd().
> >> + *
> >> + * Since event logged by libevdev are likely to end up in some files and are
> >> + * potentially attached to public bug reports, key event codes are
> >> + * obfuscated to protect accidental leakage of private information. Key
> >> + * codes between KEY_ESC up to including KEY_STOP are always logged as
> >> + * "OBFUSCATED".
> >> + *
> >>
> >> This should address some of the comments on the previous revision. It makes
> >> it easier to debug a specific device only to cut down on the log spam. And
> >> some of the security issues are alleviated by obfuscating key codes (I also
> >> need to do this for MSC_SCAN) so that a password doesn't accidentally end up
> >> in bugzilla somewhere.
> >>
> >> Comments?
> >
> > TBH, I don't really care. With structured-logging and journald, you
> > can pass the device-node as ancillary data. This way, I can just use
> > "journalctl DEVICE_NODE=eventXYZ" to filter for the device (or
> > something similar..). But the patch looks fine to me.
> >
> 
> Hmm, I don't like how these discussions usually turn into flamewar,
> but here I must say that I believe libevdev is not tight to a systemd
> environment. I really hope Android and Embedded Qt (those are the 2 I
> can think of) will switch to libevdev and hopefully libinput. And I
> doubt Android will rely on a systemd init.

libinput already uses libevdev to interact with devices.

> 
> So I am definitively in favour of being able to filter the device node
> from libevdev directly.
> 
> Cheers,
> Benjamin

Jonas


More information about the Input-tools mailing list