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 -- 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
