在 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.
Pingbo