[PATCH libevdev] In debug mode, print the events libevdev processes

[Peter Hutterer]

On Tue, Mar 18, 2014 at 10:40:09AM -0400, Benjamin Tissoires wrote:
> On Mon, Mar 17, 2014 at 10:51 PM, Peter Hutterer
> <peter.hutterer at who-t.net> wrote:
> > Sometimes bugs are really hard to reproduce with an external reader.
> > Putting a printf statement into the caller can be useful, but doesn't
> > necessarily reflect the actual events libevdev handles internally.
> >
> > Thus, in debug mode, print exactly the event we're dealing with.
> >
> > Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
> > ---
> > I'm a bit in two minds about this, feedback appreciated.
> 
> I would *not* be in favor of including this:
> - this will introduce far too much debug output to be able to get the
> right information at the right place. When debugging the SYN_DROPPED
> on synaptics, I had to add many debug outputs at different places
> around the code, but I removed the ones which hinders the more
> interesting ones. But still, I was not in the remote debugging use
> case.
> - it might be borderline or completely of topic, but couldn't it be
> considered as a security flaw? (having all the key events in the debug
> output will catch passwd and other funny things...)
> - the kernel allow us to do that, _but_ the debug api is dynamic (you
> can say: activate dbg in file.c at line 333, and even a line range),
> and you have to be root to set those debugging outputs
> 
> This is only my opinion and I can also see the interest of having that.
> I would agree more if we disable this at compile time, and give to
> people experiencing this problem a compile flag or even a binary to
> activate these debug outputs.

introducing a compile-time flag is certainly possible. or alternatively/in
addition a new debug priority for LIBEVDEV_LOG_EVENT_DEBUG or something.

another option would be to run getenv() for some "LIBEVDEV_EVENT_DEBUG"
variable in libevdev_next_event() if event logging is compile-time enabled.
This allows much more fine-grained control when the events are being
written.

I'll definitely leave this patch out for 1.1, but it's worth thinking up
some solution to this in the future.

Cheers,
   Peter

> >  libevdev/libevdev.c | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/libevdev/libevdev.c b/libevdev/libevdev.c
> > index 0730d99..84d9195 100644
> > --- a/libevdev/libevdev.c
> > +++ b/libevdev/libevdev.c
> > @@ -915,6 +915,11 @@ libevdev_next_event(struct libevdev *dev, unsigned int flags, struct input_event
> >                         dev->queue_nsync--;
> >                         sanitize_event(dev, &e);
> >                         update_state(dev, &e);
> > +                       log_dbg("internal sync event type %s (%d) code %s (%d) value %d\n",
> > +                               libevdev_event_type_get_name(e.type), e.type,
> > +                               libevdev_event_code_get_name(e.type, e.code), e.code,
> > +                               e.value);
> > +
> >                 }
> >
> >                 dev->sync_state = SYNC_NONE;
> > @@ -944,6 +949,12 @@ libevdev_next_event(struct libevdev *dev, unsigned int flags, struct input_event
> >                 if (queue_shift(dev, ev) != 0)
> >                         return -EAGAIN;
> >
> > +               log_dbg("%sevent type %s (%d) code %s (%d) value %d\n",
> > +                       (flags & LIBEVDEV_READ_FLAG_SYNC) ? "sync " : "",
> > +                       libevdev_event_type_get_name(ev->type), ev->type,
> > +                       libevdev_event_code_get_name(ev->type, ev->code), ev->code,
> > +                       ev->value);
> > +
> >                 sanitize_event(dev, ev);
> >                 update_state(dev, ev);
> >
> > --
> > 1.8.5.3
> >
> > _______________________________________________
> > Input-tools mailing list
> > Input-tools at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/input-tools