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-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
