> 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? Thanks, Henrik -- 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
