Re: [PATCH] Input: evdev - use monotonic clock for event timestamps

[Daniel Kurtz]

Hi Henrik,

On Mon, Oct 3, 2011 at 5:06 PM, Henrik Rydberg <rydberg@xxxxxxxxxxx> wrote:
>
> Hi Daniel,
>
> > Using wallclock time for event timestamps subjects inter-event timing to
> > ntp and other clock adjustments.  This complicates userspace drivers
> > that use these timestamps to calculate velocities, or while processing
> > state transitions.
> >
> > Instead, use the kernel monotonic clock for event timestamps, which is
> > at least guaranteed never to go backwards.
> >
> > Signed-off-by: Daniel Kurtz <djkurtz@xxxxxxxxxxxx>
> > ---
> >  drivers/input/evdev.c |    5 ++++-
> >  1 files changed, 4 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
> > index 4cf2534..118f936 100644
> > --- a/drivers/input/evdev.c
> > +++ b/drivers/input/evdev.c
> > @@ -94,8 +94,11 @@ static void evdev_event(struct input_handle *handle,
> >       struct evdev *evdev = handle->private;
> >       struct evdev_client *client;
> >       struct input_event event;
> > +     struct timespec now;
> >
> > -     do_gettimeofday(&event.time);
> > +     getrawmonotonic(&now);
> > +     event.time.tv_sec = now.tv_sec;
> > +     event.time.tv_usec = now.tv_nsec/1000;
> >       event.type = type;
> >       event.code = code;
> >       event.value = value;
> > --
> > 1.7.3.1
>
> Good thing per se, but reporting time relative to boot instead of
> using real time, for all input events, may cause regression on some
> obscure systems. Perhaps it is possible to improve on the desired
> monotonicity in most cases, without such a drastic change.
>
> Thanks,
> Henrik

Thanks for responding!  This is the smallest possible patch that I
could think of that illustrates what I'd like to see.  What other
options do we have to achieve the same affect?

I understand your concern about breaking random drivers, and am hoping
that someon on this list could indicate whether this is a real concern
or not.  To get a better feeling for possible regressions, I checked
xf86-input-evdev & -synaptics, and neither uses the evdev timestamp in
their current incarnations.  Any idea what else might be a good place
to check?

One option is to make the evdev timestamp clock source a per-driver
configuration option (controllable from userspace?).  This sounds like
it is doable, but would be significantly more complicated.

Another option would be to timestamp with monotonicraw + boottime +
sleeptime.  This would be approximately wall clock time, but without
ntp and slew adjustments.  But, I fear this would just make the rare
driver issue less obvious, since it would only become obvious when the
two clock sources started drifting apart.

-Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/