Thread (28 messages) 28 messages, 4 authors, 2016-10-31

Re: [PATCH v2 3/4] input: Deprecate real timestamps beyond year 2106

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: 2016-10-27 02:24:27
Also in: lkml

Hi Deepa,

On Mon, Oct 17, 2016 at 08:27:32PM -0700, Deepa Dinamani wrote:
struct timeval is not y2038 safe.
All usage of timeval in the kernel will be replaced by
y2038 safe structures.

struct input_event maintains time for each input event.
Real time timestamps are not ideal for input as this
time can go backwards as noted in the patch a80b83b7b8
by John Stultz. Hence, having the input_event.time fields
only big enough for monotonic and boot times are
sufficient.

Leave the original input_event as is. This is to maintain
backward compatibility with existing userspace interfaces
that use input_event.
Introduce a new replacement struct raw_input_event.
This replaces timeval with struct input_timeval. This structure
maintains time in __kernel_ulong_t or compat_ulong_t to allow
for architectures to override types as in the case of x32.

The change requires any userspace utilities reading or writing
from event nodes to update their reading format to match
raw_input_event. The changes to the popular libraries will be
posted along with the kernel changes.
The driver version is also updated to reflect the change in
event format.
If users are forced to update to adapt to the new event format, should
we consider more radical changes? For example, does it make sense to
send timestamp on every event? Maybe we should only send it once per
event packet (between EV_SYN/SYN_REPORT)? What granularity do we need?
Is there anything else in current protocol that we'd like to change?

Thanks.

-- 
Dmitry
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help