Re: [PATCH 0/3] introduce new evdev interface type

2015-12-03 Thread Pingbo Wen
> 在 2015年12月1日，18:47，Arnd Bergmann 写道： > > On Tuesday 01 December 2015 16:34:00 Pingbo Wen wrote: >> >> >> What kinds of changes in time_t? Extending it to 64-bits in both kernel >> and userspace? Ok, I get confused here, if there are some sample codes >> or use-cases here, it will help me a l

Re: [Y2038] [PATCH 0/3] introduce new evdev interface type

2015-12-03 Thread Arnd Bergmann
On Thursday 03 December 2015 13:54:47 Arnd Bergmann wrote: > > > struct input_event { > > > #if !defined(__KERNEL__) && __TIME_T_BITS == __BITS_PER_LONG > > >struct timeval time; > > > > > #else > > > struct { > > > union { > > > __u32 tv_sec __attribute

Re: [Y2038] [PATCH 0/3] introduce new evdev interface type

2015-12-03 Thread Arnd Bergmann
On Thursday 03 December 2015 20:49:06 Pingbo Wen wrote: > > 在 2015年12月1日，18:47，Arnd Bergmann 写道： > > On Tuesday 01 December 2015 16:34:00 Pingbo Wen wrote: > >> We can force kernel using monotonic time in EV_IF_LEGACY interface, and > >> making input_event independent from time_t(after evdev has c

Re: [PATCH 0/3] introduce new evdev interface type

2015-12-01 Thread Arnd Bergmann
On Tuesday 01 December 2015 16:34:00 Pingbo Wen wrote: > Hi, Arnd > > > The patch series add three evdev interface type: > > - EV_IF_LEGACY > send event by input_event. This is the default option, keep kernel > backward compatible. > >>> > >>> The problem I see wit

Re: [PATCH 0/3] introduce new evdev interface type

2015-12-01 Thread Pingbo Wen
Hi, Arnd The patch series add three evdev interface type: - EV_IF_LEGACY send event by input_event. This is the default option, keep kernel backward compatible. >>> >>> The problem I see with this approach is that it still breaks any >>> legacy source code that is

Re: [PATCH 0/3] introduce new evdev interface type

2015-12-01 Thread Pingbo Wen
Hi, Arnd The patch series add three evdev interface type: - EV_IF_LEGACY send event by input_event. This is the default option, keep kernel backward compatible. >>> >>> The problem I see with this approach is that it still breaks any >>> legacy source code that is

Re: [PATCH 0/3] introduce new evdev interface type

2015-11-30 Thread Arnd Bergmann
On Sunday 29 November 2015 17:13:50 Pingbo Wen wrote: > > 在 2015年11月28日，00:58，Arnd Bergmann 写道： > > > > On Friday 27 November 2015 18:00:29 WEN Pingbo wrote: > >> To solve the y2038 problem in input_event, I had some attempts before [1], > >> and this is the second one. > >> > >> We can force us

Re: [PATCH 0/3] introduce new evdev interface type

2015-11-29 Thread Pingbo Wen
Hi, Arnd > 在 2015年11月28日，00:58，Arnd Bergmann 写道： > > On Friday 27 November 2015 18:00:29 WEN Pingbo wrote: >> To solve the y2038 problem in input_event, I had some attempts before [1], >> and this is the second one. >> >> We can force userspace to use monotonic time in event timestamp, so the >

Re: [PATCH 0/3] introduce new evdev interface type

2015-11-27 Thread Arnd Bergmann
On Friday 27 November 2015 18:00:29 WEN Pingbo wrote: > To solve the y2038 problem in input_event, I had some attempts before [1], > and this is the second one. > > We can force userspace to use monotonic time in event timestamp, so the > 'struct timeval' is enough to keep y2038-safe, as Arnd sugg

[PATCH 0/3] introduce new evdev interface type

2015-11-27 Thread WEN Pingbo
To solve the y2038 problem in input_event, I had some attempts before [1], and this is the second one. We can force userspace to use monotonic time in event timestamp, so the 'struct timeval' is enough to keep y2038-safe, as Arnd suggested. But we can not find a way to make kernel compatible with