[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGS+omAj9z2-Au2HABtDKHQGRBNVxXygF2cz+L8UMeTHRrMjbA@mail.gmail.com>
Date: Wed, 5 Oct 2011 15:55:05 +0800
From: Daniel Kurtz <djkurtz@...omium.org>
To: Henrik Rydberg <rydberg@...omail.se>
Cc: dmitry.torokhov@...il.com, linux-input@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Input: evdev - use monotonic clock for event timestamps
Hi Henrik,
On Mon, Oct 3, 2011 at 5:06 PM, Henrik Rydberg <rydberg@...omail.se> 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@...omium.org>
> > ---
> > 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists