On Thu, 2017-12-14 at 13:44 -0800, Deepa Dinamani wrote:

On Thu, Dec 14, 2017 at 1:18 PM, Ben Hutchings

quoted

[off-list ref] wrote:
On Thu, 2017-12-14 at 21:17 +0000, Ben Hutchings wrote:

quoted

On Thu, 2017-12-07 at 10:13 -0800, Deepa Dinamani wrote:

quoted

struct timeval which is part of struct input_event to
maintain the event times is not y2038 safe.

Real time timestamps are also not ideal for input_event
as this time can go backwards as noted in the patch
a80b83b7b8 by John Stultz.

The patch switches the timestamps to use monotonic time
from realtime time. This is assuming no one is using
absolute times from these timestamps.

Why is this change not opt-in, as for evdev?  I assume there were
compatibility reasons for not changing evdev's clock by default, so I
would expect them to apply to uinput as well.  (But I'm also prepared
to believe that user-space is now generally compatible with and would
prefer monotonic time from all input devices.)

Never mind, I've gone back and seen Arnd's comments about compatibility
on v3.  It might be worth copying those into the commit message though.

Commit message already talks about this assumption?:

The patch switches the timestamps to use monotonic time
from realtime time. This is assuming no one is using
absolute times from these timestamps.

Yes, but Arnd did a bit of code research to check that assumption.
A commit message that says "we checked and it appears that no user-
space depends on this" looks better than "I assume that no user-space
depends on this".

Ben.

-- 
Ben Hutchings
Software Developer, Codethink Ltd.