Messages in this thread | | | Date | Wed, 05 Oct 2011 15:35:11 +0100 | From | Chase Douglas <> | Subject | Re: [PATCH] Input: evdev - use monotonic clock for event timestamps |
| |
On 10/05/2011 10:23 AM, Henrik Rydberg wrote: >> 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? > > The input system is used for all sorts of events - switches, for > instance. The point is that it is nearly impossible to know if > something will break or not, hence the reluctance to modify interfaces. > >> 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. > > I agree, the problem is not really solvable. Dmitry?
We could put it into the -next tree early on in the cycle, and then it will be in -next for a cycle and in Linus' tree for the real dev cycle. By that time we would hope any issues would have emerged.
I'm not sure if that is a responsible approach. I agree that the change would be good, but how sure would we be that nothing would break based only on testing in development trees?
My personal thoughts are that I doubt it would cause issues. Based on that gut feel, I would say that this approach is reasonable. However, I'm just one voice in all this :).
-- Chase
| |