On Wednesday 04 November 2015 11:35:20 Pingbo Wen wrote:
在 2015年11月3日，09:43，Dmitry Torokhov dmitry.torokhov@gmail.com 写道：
On Mon, Nov 02, 2015 at 09:35:36PM +0800, WEN Pingbo wrote:
Before this, I have discussed this problem with Arnd. And Arnd have an idea that by converting timeval to long / long in input_event, so that input_event structure size will be unchanged, and timeval structure will removed entirely. But we also need to avoid using CLOCK_REALTIME in userland, to keep the new input_event structure y2038 safe.
The input_event will only support monotonic time in Arnd's idea. And we still need to add wall time support for old 32-bit binary.
Those patches try to keep original input capacity, and resolve y2038 problem in input_event radically.
struct input_event is only used between kernel and userspace communication (except uinput). So that we can replace input_event with input_event64 in kernel entirely, and add a conversion in input_event_from/to_user() to keep compatible with old 32-bits binary.
userland can switch to input_event64, which is y2038 safe, via ioctl.
If we are forcing userspace to change the protocol I'd rather explore whether we need to transmit the timestamp in each and every event. I would much rather drop it and instead introduce new event code for timestamp (we already have MSC_TIMESTAMP for hardware-generated timestamps, maybe we can introduce new ones for kernel-generated timestamps).
Yes, we can do that by replacing all input_event with input_value in kernel, and injecting a timestamp event after every normal event (maybe we can give userspace a option here).
But we still need do some conversion work in input_event_from/to_user to be compatible with old binary. And we need extend value field in ’struct input_value’ to s64, so the timestamp can be passed safely.
Right, that would be equivalent to Pingbo's approach (fixing the y2038 problem by requiring user space changes that are incompatible with old kernels), but with a nicer interface.
The approach of leaving the event timestamps as 32 bit but requiring montonic times in contrast would require only user space to change when it cares about time stamps and doesn't already use montonic times. Importantly, the modified user space would remain compatible with older kernels as long as they support monotonic times. Those were introduced by John Stultz in a80b83b7b8 ("Input: add infrastructure for selecting clockid for event time stamps") and merged into linux-3.3, and are generally a good idea because of time jumps.
Arnd