Reposting the series as I did not hear comments from the
maintainers.
The series is aimed at making input events y2038 safe.
It extends the lifetime of the realtime timestamps in the
events to year 2106.
The plan is to deprecate realtime timestamps anyway as they
are not appropriate for these timestamps as noted in the patch
a80b83b7b8 by John Stultz.
The series is a result of many discussions with Arnd Bergmann.
The design updates the format of the input events read/ written
to the device nodes. This structure and the uapi/input.h
header file are copied across many userspace libraries.
These libraries not only use this struct input_event locally,
but also expose interfaces that contain input_event. To maintain
backward compatibility with all these interfaces, kernel
updates the format of the input events at the dev node to
struct raw_input_event. Kernel also maintains the old struct
input_event and provides apis to convert between the old and new
input event types.
The userspace library changes to libevdev, libuinput and mtdev
will be posted to the respective mailing groups for review.
Once there is a consensus on the design, all the changes dependent
on the kernel change will be merged at the same time.
Changes from v1:
* Updated changes according to review comments.
* Posted userspace library changes that go along with the series.
Deepa Dinamani (4):
uinput: Add ioctl for using monotonic/ boot times
input: evdev: Replace timeval with timespec64
input: Deprecate real timestamps beyond year 2106
input: serio: Replace timeval by timespec64
drivers/input/evdev.c | 57 ++++++++++++++++++++----------------
drivers/input/input-compat.c | 29 ++++++++++---------
drivers/input/input-compat.h | 19 +++++++-----
drivers/input/misc/uinput.c | 62 +++++++++++++++++++++++++++++++++++++---
drivers/input/serio/hil_mlc.c | 37 ++++++++++++------------
drivers/input/serio/hp_sdc.c | 17 +++++------
drivers/input/serio/hp_sdc_mlc.c | 10 +++----
include/linux/hil_mlc.h | 6 ++--
include/linux/hp_sdc.h | 6 ++--
include/linux/uinput.h | 3 +-
include/uapi/linux/input.h | 47 ++++++++++++++++++++++++++++++
include/uapi/linux/uinput.h | 3 ++
12 files changed, 208 insertions(+), 88 deletions(-)
--
2.7.4
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.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Deepa Dinamani <redacted>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/input/evdev.c | 20 +++++++++----------
drivers/input/input-compat.c | 29 ++++++++++++++-------------
drivers/input/input-compat.h | 19 +++++++++++-------
drivers/input/misc/uinput.c | 6 +++---
include/linux/uinput.h | 2 +-
include/uapi/linux/input.h | 47 ++++++++++++++++++++++++++++++++++++++++++++
6 files changed, 88 insertions(+), 35 deletions(-)
@@ -22,6 +22,29 @@*Theeventstructureitself*/+/* The time structure for y2038 safe raw_input_event.+*Thefieldsuseunsignedtypestoextendtimesuntil+*year2106ratherthan2038.+*/+structinput_timeval{+__kernel_ulong_ttv_sec;+__kernel_ulong_ttv_usec;+};++structraw_input_event{+structinput_timevaltime;+__u16type;+__u16code;+__s32value;+};++#ifndef __KERNEL__++/* Userspace structure.+*Definitionmaintainedhereforuserspacethatisnotyetupdatedtouse+*structraw_input_event.+*Nottobeusedanywherewithinthekernel.+*/structinput_event{structtimevaltime;__u16type;
struct timeval is not y2038 safe.
All references to timeval will be deleted from the
kernel to make it y2038 safe.
Replace its uses by y2038 safe struct timespec64.
The timestamps changed here only keep track of delta
times. These timestamps are also internal to kernel.
Hence, monotonic times are sufficient here.
The unit of the delta times is also changed in certain
cases to nanoseconds rather than microseconds. This is
in line with timespec64 which keeps time in nanoseconds.
Signed-off-by: Deepa Dinamani <redacted>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/input/serio/hil_mlc.c | 37 ++++++++++++++++++-------------------
drivers/input/serio/hp_sdc.c | 17 +++++++++--------
drivers/input/serio/hp_sdc_mlc.c | 10 +++++-----
include/linux/hil_mlc.h | 6 +++---
include/linux/hp_sdc.h | 6 +++---
5 files changed, 38 insertions(+), 38 deletions(-)
@@ -274,14 +274,14 @@ static int hilse_match(hil_mlc *mlc, int unused)/* An LCV used to prevent runaway loops, forces 5 second sleep when reset. */staticinthilse_init_lcv(hil_mlc*mlc,intunused){-structtimevaltv;+time64_ttime;-do_gettimeofday(&tv);+time=ktime_get_seconds();-if(mlc->lcv&&(tv.tv_sec-mlc->lcv_tv.tv_sec)<5)+if(mlc->lcv&&(time-mlc->lcv_tv.tv_sec)<5)return-1;-mlc->lcv_tv=tv;+mlc->lcv_tv.tv_sec=time;mlc->lcv=0;return0;
@@ -193,7 +193,7 @@ static void hp_sdc_take(int irq, void *dev_id, uint8_t status, uint8_t data)curr->seq[curr->idx++]=status;curr->seq[curr->idx++]=data;hp_sdc.rqty-=2;-do_gettimeofday(&hp_sdc.rtv);+ktime_get_ts64(&hp_sdc.rtv);if(hp_sdc.rqty<=0){/* All data has been gathered. */
@@ -306,13 +306,13 @@ static void hp_sdc_tasklet(unsigned long foo)write_lock_irq(&hp_sdc.rtq_lock);if(hp_sdc.rcurr>=0){-structtimevaltv;+structtimespec64ts;-do_gettimeofday(&tv);-if(tv.tv_sec>hp_sdc.rtv.tv_sec)-tv.tv_usec+=USEC_PER_SEC;+ktime_get_ts64(&ts);+if(ts.tv_sec>hp_sdc.rtv.tv_sec)+ts.tv_nsec+=NSEC_PER_SEC;-if(tv.tv_usec-hp_sdc.rtv.tv_usec>HP_SDC_MAX_REG_DELAY){+if(ts.tv_nsec-hp_sdc.rtv.tv_nsec>HP_SDC_MAX_REG_DELAY){hp_sdc_transaction*curr;uint8_ttmp;
@@ -551,7 +552,7 @@ unsigned long hp_sdc_put(void)/* Start a new read */hp_sdc.rqty=curr->seq[curr->idx];-do_gettimeofday(&hp_sdc.rtv);+ktime_get_ts64(&hp_sdc.rtv);curr->idx++;/* Still need to lock here in case of spurious irq. */write_lock_irq(&hp_sdc.rtq_lock);
@@ -149,7 +149,7 @@ static int hp_sdc_mlc_in(hil_mlc *mlc, suseconds_t timeout)/* Try to down the semaphore */if(down_trylock(&mlc->isem)){-structtimevaltv;+structtimespec64ts;if(priv->emtestmode){mlc->ipacket[0]=HIL_ERR_INT|(mlc->opacket&
@@ -144,12 +144,12 @@ struct hil_mlc {hil_packetipacket[16];hil_packetimatch;inticount;-structtimevalinstart;+structtimespec64instart;suseconds_tintimeout;intddi;/* Last operational device id */intlcv;/* LCV to throttle loops */-structtimevallcv_tv;/* Time loop was started */+structtimespec64lcv_tv;/* Time loop was started */intdi_map[7];/* Maps below items to live devs */structhil_mlc_devinfodi[HIL_MLC_DEVMEM];
@@ -47,9 +47,9 @@#endif-/* No 4X status reads take longer than this (in usec).+/* No 4X status reads take longer than this (in nsec).*/-#define HP_SDC_MAX_REG_DELAY 20000+#define HP_SDC_MAX_REG_DELAY 20000000typedefvoid(hp_sdc_irqhook)(intirq,void*dev_id,uint8_tstatus,uint8_tdata);
@@ -281,7 +281,7 @@ typedef struct {hp_sdc_transaction*tq[HP_SDC_QUEUE_LEN];/* All pending read/writes */intrcurr,rqty;/* Current read transact in process */-structtimevalrtv;/* Time when current read started */+structtimespec64rtv;/* Monotonic time when current read started */intwcurr;/* Current write transact in process */intdev_err;/* carries status from registration */
struct timeval is not y2038 safe.
All references to timeval in the kernel will be replaced
by y2038 safe structures.
Replace all references to timeval with y2038 safe
struct timespec64 here.
struct input_event will be changed in a different patch.
Signed-off-by: Deepa Dinamani <redacted>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/input/evdev.c | 37 +++++++++++++++++++++++--------------
1 file changed, 23 insertions(+), 14 deletions(-)
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.
Arnd Bergmann suggested deprecating real time and using
monotonic or other timers for all input_event times as a
solution to both the above problems.
Add a new ioctl to let the user dictate the kind of time
to be used for input events. This is similar to the evdev
implementation of the feature. Realtime is still the
default time. This is to maintain backward compatibility.
The structure to maintain input events will be changed
in a different patch.
Signed-off-by: Deepa Dinamani <redacted>
---
drivers/input/misc/uinput.c | 56 ++++++++++++++++++++++++++++++++++++++++++++-
include/linux/uinput.h | 1 +
include/uapi/linux/uinput.h | 3 +++
3 files changed, 59 insertions(+), 1 deletion(-)
@@ -46,11 +46,26 @@ static int uinput_dev_event(struct input_dev *dev,unsignedinttype,unsignedintcode,intvalue){structuinput_device*udev=input_get_drvdata(dev);+structtimespec64ts;udev->buff[udev->head].type=type;udev->buff[udev->head].code=code;udev->buff[udev->head].value=value;-do_gettimeofday(&udev->buff[udev->head].time);++switch(udev->clk_type){+caseCLOCK_REALTIME:+ktime_get_real_ts64(&ts);+break;+caseCLOCK_MONOTONIC:+ktime_get_ts64(&ts);+break;+caseCLOCK_BOOTTIME:+get_monotonic_boottime64(&ts);+break;+}++udev->buff[udev->head].time.tv_sec=ts.tv_sec;+udev->buff[udev->head].time.tv_usec=ts.tv_nsec/NSEC_PER_USEC;udev->head=(udev->head+1)%UINPUT_BUFFER_SIZE;wake_up_interruptible(&udev->waitq);
@@ -295,6 +310,7 @@ static int uinput_create_device(struct uinput_device *udev)if(error)gotofail2;+udev->clk_type=CLOCK_REALTIME;udev->state=UIST_CREATED;return0;
@@ -304,6 +320,38 @@ static int uinput_create_device(struct uinput_device *udev)returnerror;}+staticintuinput_set_clk_type(structuinput_device*udev,unsignedintclkid)+{+unsignedintclk_type;++if(udev->state!=UIST_CREATED)+return-EINVAL;++switch(clkid){+/* Realtime clock is only valid until year 2038.*/+caseCLOCK_REALTIME:+clk_type=CLOCK_REALTIME;+break;+caseCLOCK_MONOTONIC:+clk_type=CLOCK_MONOTONIC;+break;+caseCLOCK_BOOTTIME:+clk_type=CLOCK_BOOTTIME;+break;+default:+return-EINVAL;+}++if(udev->clk_type!=clk_type){+udev->clk_type=clk_type;++/* Flush pending events */+uinput_flush_requests(udev);+}++return0;+}+staticintuinput_open(structinode*inode,structfile*file){structuinput_device*newdev;
@@ -787,6 +835,7 @@ static long uinput_ioctl_handler(struct file *file, unsigned int cmd,char*phys;constchar*name;unsignedintsize;+intclock_id;retval=mutex_lock_interruptible(&udev->mutex);if(retval)
@@ -817,6 +866,11 @@ static long uinput_ioctl_handler(struct file *file, unsigned int cmd,retval=uinput_dev_setup(udev,p);gotoout;+caseUI_SET_CLOCKID:+if(copy_from_user(&clock_id,p,sizeof(unsignedint)))+return-EFAULT;+returnuinput_set_clk_type(udev,clock_id);+/* UI_ABS_SETUP is handled in the variable size ioctls */caseUI_SET_EVBIT:
From: Peter Hutterer <hidden> Date: 2016-10-27 01:45:20
On Mon, Oct 17, 2016 at 08:27:30PM -0700, Deepa Dinamani wrote:
quoted hunk
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.
Arnd Bergmann suggested deprecating real time and using
monotonic or other timers for all input_event times as a
solution to both the above problems.
Add a new ioctl to let the user dictate the kind of time
to be used for input events. This is similar to the evdev
implementation of the feature. Realtime is still the
default time. This is to maintain backward compatibility.
The structure to maintain input events will be changed
in a different patch.
Signed-off-by: Deepa Dinamani <redacted>
---
drivers/input/misc/uinput.c | 56 ++++++++++++++++++++++++++++++++++++++++++++-
include/linux/uinput.h | 1 +
include/uapi/linux/uinput.h | 3 +++
3 files changed, 59 insertions(+), 1 deletion(-)
@@ -46,11 +46,26 @@ static int uinput_dev_event(struct input_dev *dev,unsignedinttype,unsignedintcode,intvalue){structuinput_device*udev=input_get_drvdata(dev);+structtimespec64ts;udev->buff[udev->head].type=type;udev->buff[udev->head].code=code;udev->buff[udev->head].value=value;-do_gettimeofday(&udev->buff[udev->head].time);++switch(udev->clk_type){+caseCLOCK_REALTIME:+ktime_get_real_ts64(&ts);+break;+caseCLOCK_MONOTONIC:+ktime_get_ts64(&ts);+break;+caseCLOCK_BOOTTIME:+get_monotonic_boottime64(&ts);+break;+}
hmm, I'm a bit confused here. This is an in-kernel bit only (passing the
time through uinput events has no effect). So why do we need an ioctl here?
it's an in-kernel decision only anyway and the time in the events sent to
the evdev client should be dictated by what that client sets for the clock
type, right?
Cheers,
Peter
@@ -133,6 +133,9 @@ struct uinput_abs_setup {*/#define UI_ABS_SETUP _IOW(UINPUT_IOCTL_BASE, 4, struct uinput_abs_setup)+/* Set clockid to be used for timestamps */+#define UI_SET_CLOCKID _IOW(UINPUT_IOCTL_BASE, 5, int)+#define UI_SET_EVBIT _IOW(UINPUT_IOCTL_BASE, 100, int)#define UI_SET_KEYBIT _IOW(UINPUT_IOCTL_BASE, 101, int)#define UI_SET_RELBIT _IOW(UINPUT_IOCTL_BASE, 102, int)
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Peter Hutterer <hidden> Date: 2016-10-27 01:57:17
On Mon, Oct 17, 2016 at 08:27:31PM -0700, Deepa Dinamani wrote:
quoted hunk
struct timeval is not y2038 safe.
All references to timeval in the kernel will be replaced
by y2038 safe structures.
Replace all references to timeval with y2038 safe
struct timespec64 here.
struct input_event will be changed in a different patch.
Signed-off-by: Deepa Dinamani <redacted>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/input/evdev.c | 37 +++++++++++++++++++++++--------------
1 file changed, 23 insertions(+), 14 deletions(-)
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
From: Peter Hutterer <hidden> Date: 2016-10-27 02:56:32
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.
general comment here - please don't name it "raw_input_event".
First, when you grep for input_event you want the new ones to show up too,
so a struct input_event_raw would be better here. That also has better
namespacing in general. Second though: the event isn't any more "raw" than
the previous we had.
I can't think of anything better than struct input_event_v2 though.
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.
Doesn't this break *all* of userspace then? I don't see anything to
negotiate the type of input event the kernel gives me. And nothing right now
checks for EVDEV_VERSION, so they all just assume it's a struct
input_event. Best case, if the available events aren't a multiple of
sizeof(struct input_event) userspace will bomb out, but unless that happens,
everyone will just happily read old-style events.
So we need some negotiation what is acceptable. Which also needs to address
the race conditions we're going to get when events start coming in before
the client has announced that it supports the new-style events.
Cheers,
Peter
@@ -22,6 +22,29 @@*Theeventstructureitself*/+/* The time structure for y2038 safe raw_input_event.+*Thefieldsuseunsignedtypestoextendtimesuntil+*year2106ratherthan2038.+*/+structinput_timeval{+__kernel_ulong_ttv_sec;+__kernel_ulong_ttv_usec;+};++structraw_input_event{+structinput_timevaltime;+__u16type;+__u16code;+__s32value;+};++#ifndef __KERNEL__++/* Userspace structure.+*Definitionmaintainedhereforuserspacethatisnotyetupdatedtouse+*structraw_input_event.+*Nottobeusedanywherewithinthekernel.+*/structinput_event{structtimevaltime;__u16type;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
you have ktime_get_* helpers below but you don't have one for timespec64 to
struct timeval? That seems like a bug waitig to happen.
This is intentional to a certain degree: we don't have a timeval64
because any conversion to a new interface should prefer timespec64
or 64-bit nanoseconds, and we try to remove timeval (along with
timespec) from everywhere in the kernel because basically all uses
are problematic for y2038.
Note that after patch 3, event->time is no longer a 'timeval'
either, so even if we had a conversion function, we could
no longer use it here.
Arnd
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
hmm, I'm a bit confused here. This is an in-kernel bit only (passing the
time through uinput events has no effect). So why do we need an ioctl here?
it's an in-kernel decision only anyway and the time in the events sent to
the evdev client should be dictated by what that client sets for the clock
type, right?
This is for input events queued by the uinput driver for the virtual
input device.
This can be read through uinput_read() fops.
I don't think anybody is doing a read on uinput nodes, so another
option(Arnd and I considered this) could be not supporting reads on
these nodes at all.
This is not related to evdev events in the kernel.
Currently, this timestamp could be the same format as the evdev
timestamps or not.
-Deepa
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
On Wed, Oct 26, 2016 at 7:56 PM, Peter Hutterer
[off-list ref] wrote:
On Mon, Oct 17, 2016 at 08:27:32PM -0700, Deepa Dinamani wrote:
quoted
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.
general comment here - please don't name it "raw_input_event".
First, when you grep for input_event you want the new ones to show up too,
so a struct input_event_raw would be better here. That also has better
namespacing in general. Second though: the event isn't any more "raw" than
the previous we had.
I can't think of anything better than struct input_event_v2 though.
The general idea was to leave the original struct input_event as a
common interface for userspace (as it cannot be deleted).
So reading raw data unformatted by the userspace will have the new
struct raw_input_event format.
This was the reason for the "raw" in the name.
struct input_event_v2 is fine too, if this is more preferred.
quoted
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.
Doesn't this break *all* of userspace then? I don't see anything to
negotiate the type of input event the kernel gives me. And nothing right now
checks for EVDEV_VERSION, so they all just assume it's a struct
input_event. Best case, if the available events aren't a multiple of
sizeof(struct input_event) userspace will bomb out, but unless that happens,
everyone will just happily read old-style events.
So we need some negotiation what is acceptable. Which also needs to address
the race conditions we're going to get when events start coming in before
the client has announced that it supports the new-style events.
No, this does not break any userspace right now.
Both struct input_event and struct raw_input_event are exactly the same today.
This will be the case until a 2038-safe glibc is used with a 64 bit time_t flag.
So these are the scenarios:
1. old kernel driver + new userspace
-- should still be ok until 2038. Version checks could help discover these
2. new kernel driver + old userspace (without recompiled with new 2038 gblic)
-- works because the format is really the same.
The patch I posted to libevdev checks this driver version.
And, hence any library that results in a call to libevdev_set_fd()
will fail if it is not this updated driver.
We could just do a similar check in every library also.
I think the latter would be better.
So, the kernel patches can go in as a no-op right now and then I can
add version checks to respective user space libraries.
-Deepa
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
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?
I did see the thread with Pingbo's patches where you had a similar comment.
I see my series as decoupling the kernel input event format from the
userspace format.
The formats also are really the same still.
Could this be considered the first step towards changing the protocol?
The protocol changes might need new interfaces to be defined between libraries.
And, could end up being a substantial change.
Would a step by step approach make sense?
-Deepa
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
On Thu, Oct 27, 2016 at 03:25:43PM -0700, Deepa Dinamani wrote:
quoted
quoted
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?
I did see the thread with Pingbo's patches where you had a similar comment.
I see my series as decoupling the kernel input event format from the
userspace format.
The formats also are really the same still.
Could this be considered the first step towards changing the protocol?
I really do not see the point. I think we agree that the current
protocol is not working past 2038 and it does not seem we can fix it
transparently for the user. So we need to define new protocol and let
kernel and clients negotiate which one is used.
I am not concerned about in-kernel representation much as it does not
get stored anywhere so we can adjust it as needed without too much
effort.
The protocol changes might need new interfaces to be defined between libraries.
And, could end up being a substantial change.
Would a step by step approach make sense?
It would depend largely on the scope.
Thanks.
--
Dmitry
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
From: Peter Hutterer <hidden> Date: 2016-10-28 04:33:12
On Thu, Oct 27, 2016 at 01:39:30PM -0700, Deepa Dinamani wrote:
quoted
hmm, I'm a bit confused here. This is an in-kernel bit only (passing the
time through uinput events has no effect). So why do we need an ioctl here?
it's an in-kernel decision only anyway and the time in the events sent to
the evdev client should be dictated by what that client sets for the clock
type, right?
This is for input events queued by the uinput driver for the virtual
input device.
oh, right. I thought this was in the path for uinput_write(). sorry about
that.
This can be read through uinput_read() fops.
I don't think anybody is doing a read on uinput nodes, so another
option(Arnd and I considered this) could be not supporting reads on
these nodes at all.
This is not related to evdev events in the kernel.
Currently, this timestamp could be the same format as the evdev
timestamps or not.
I can say I've never done the read from the uinput device, never even
occured to me. quick skim of the code looks like this only matters for
force_feedback stuff. can't really comment on that too much.
Cheers,
Peter
From: Peter Hutterer <hidden> Date: 2016-10-28 04:46:53
On Thu, Oct 27, 2016 at 03:24:55PM -0700, Deepa Dinamani wrote:
On Wed, Oct 26, 2016 at 7:56 PM, Peter Hutterer
[off-list ref] wrote:
quoted
On Mon, Oct 17, 2016 at 08:27:32PM -0700, Deepa Dinamani wrote:
quoted
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.
general comment here - please don't name it "raw_input_event".
First, when you grep for input_event you want the new ones to show up too,
so a struct input_event_raw would be better here. That also has better
namespacing in general. Second though: the event isn't any more "raw" than
the previous we had.
I can't think of anything better than struct input_event_v2 though.
The general idea was to leave the original struct input_event as a
common interface for userspace (as it cannot be deleted).
So reading raw data unformatted by the userspace will have the new
struct raw_input_event format.
This was the reason for the "raw" in the name.
struct input_event_v2 is fine too, if this is more preferred.
quoted
quoted
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.
Doesn't this break *all* of userspace then? I don't see anything to
negotiate the type of input event the kernel gives me. And nothing right now
checks for EVDEV_VERSION, so they all just assume it's a struct
input_event. Best case, if the available events aren't a multiple of
sizeof(struct input_event) userspace will bomb out, but unless that happens,
everyone will just happily read old-style events.
So we need some negotiation what is acceptable. Which also needs to address
the race conditions we're going to get when events start coming in before
the client has announced that it supports the new-style events.
No, this does not break any userspace right now.
Both struct input_event and struct raw_input_event are exactly the same today.
oh, right, the ABI is the same. I see that now, thanks.
This will be the case until a 2038-safe glibc is used with a 64 bit time_t flag.
So these are the scenarios:
1. old kernel driver + new userspace
-- should still be ok until 2038. Version checks could help discover these
2. new kernel driver + old userspace (without recompiled with new 2038 gblic)
-- works because the format is really the same.
The patch I posted to libevdev checks this driver version.
btw, where did you post the libevdev patch? I haven't seen it anywhere I'm
subscribed to.
And, hence any library that results in a call to libevdev_set_fd()
will fail if it is not this updated driver.
without having seen the libevdev patch - that sounds like a bad idea . there
are plenty of usecases where libevdev_set_fd() is called but timestamps in
events just don't matter. So we may need need some more negotiation between
the library user, libevdev and the kernel.
Cheers,
Peter
We could just do a similar check in every library also.
I think the latter would be better.
So, the kernel patches can go in as a no-op right now and then I can
add version checks to respective user space libraries.
On Thursday, October 27, 2016 4:12:54 PM CEST Dmitry Torokhov wrote:
On Thu, Oct 27, 2016 at 03:25:43PM -0700, Deepa Dinamani wrote:
quoted
quoted
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?
I did see the thread with Pingbo's patches where you had a similar comment.
I see my series as decoupling the kernel input event format from the
userspace format.
The formats also are really the same still.
Could this be considered the first step towards changing the protocol?
I really do not see the point. I think we agree that the current
protocol is not working past 2038 and it does not seem we can fix it
transparently for the user. So we need to define new protocol and let
kernel and clients negotiate which one is used.
This work is not primarily about fixing the protocol to work beyond
2038 (although as a side-effect it will work until 2106). The
main intention here is to not break existing applications when
they get recompiled against a C library that defines time_t as
64-bit.
I am not concerned about in-kernel representation much as it does not
get stored anywhere so we can adjust it as needed without too much
effort.
quoted
The protocol changes might need new interfaces to be defined between libraries.
And, could end up being a substantial change.
Would a step by step approach make sense?
It would depend largely on the scope.
I think we should do those two things completely independently.
We need to do something now to preserve the current interfaces
for the glibc changes that are coming soon [1], and Deepa's
patches do that (though I now realize the changelog doesn't
mention the requirement).
An overhaul of the input_event handling with a new modern
but incompatible format may or may not be a good idea, but
this should be decided independently.
Arnd
[1] https://sourceware.org/glibc/wiki/Y2038ProofnessDesign
On Friday, October 28, 2016 2:46:42 PM CEST Peter Hutterer wrote:
On Thu, Oct 27, 2016 at 03:24:55PM -0700, Deepa Dinamani wrote:
quoted
On Wed, Oct 26, 2016 at 7:56 PM, Peter Hutterer
[off-list ref] wrote:
quoted
On Mon, Oct 17, 2016 at 08:27:32PM -0700, Deepa Dinamani wrote:
general comment here - please don't name it "raw_input_event".
First, when you grep for input_event you want the new ones to show up too,
so a struct input_event_raw would be better here. That also has better
namespacing in general. Second though: the event isn't any more "raw" than
the previous we had.
I can't think of anything better than struct input_event_v2 though.
The general idea was to leave the original struct input_event as a
common interface for userspace (as it cannot be deleted).
So reading raw data unformatted by the userspace will have the new
struct raw_input_event format.
This was the reason for the "raw" in the name.
struct input_event_v2 is fine too, if this is more preferred.
I think input_event_v2 would be more confusing. An alternative
to raw_input_event might be __kernel_input_event, which parallels
things like __kernel_off_t that is also independent from the user
space off_t in the same way that the user space input_event
structure will get redefined in a way that is incompatible with
the kernel ABI.
quoted
quoted
quoted
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.
Doesn't this break *all* of userspace then? I don't see anything to
negotiate the type of input event the kernel gives me. And nothing right now
checks for EVDEV_VERSION, so they all just assume it's a struct
input_event. Best case, if the available events aren't a multiple of
sizeof(struct input_event) userspace will bomb out, but unless that happens,
everyone will just happily read old-style events.
So we need some negotiation what is acceptable. Which also needs to address
the race conditions we're going to get when events start coming in before
the client has announced that it supports the new-style events.
No, this does not break any userspace right now.
Both struct input_event and struct raw_input_event are exactly the same today.
oh, right, the ABI is the same. I see that now, thanks.
One minor difference is that the seconds in raw_input_event are
'unsigned', so even with the 'real' time domain, we can represent
times from 1970 to 2106, whereas 'timeval' represents times between
1902 and 2038.
Once user space has a 64-bit time_t and the conversion function
in libinput that Deepa suggested, the raw_input_event is only
used on the kernel ABI and the normal timestamps will work fine.
quoted
And, hence any library that results in a call to libevdev_set_fd()
will fail if it is not this updated driver.
without having seen the libevdev patch - that sounds like a bad idea . there
are plenty of usecases where libevdev_set_fd() is called but timestamps in
events just don't matter. So we may need need some more negotiation between
the library user, libevdev and the kernel.
I also don't see any strict dependency at all: the binary data format
has not changed, and I agree we absolutely should not break running
a newly built library on old kernels.
We can also safely assume that any user space that is actually built
for 64-bit time_t is also running on a recent enough kernel,
as today's kernels do not support 64-bit time_t yet.
Arnd
This is a variation of the problem we are trying to solve for
the other architectures in your patch set:
On x32, the kernel uses produces a structure with the 64-bit
layout, using __u64 tv_sec, to match the current user space
that has 64-bit __kernel_ulong_t and 64-bit time_t, but
in_compat_syscall() also returns 'true' here, as this is
mostly a 32-bit ABI (time_t being one of the exceptions).
ARnd
This is a variation of the problem we are trying to solve for
the other architectures in your patch set:
On x32, the kernel uses produces a structure with the 64-bit
layout, using __u64 tv_sec, to match the current user space
that has 64-bit __kernel_ulong_t and 64-bit time_t, but
in_compat_syscall() also returns 'true' here, as this is
mostly a 32-bit ABI (time_t being one of the exceptions).
Yes, I missed this.
in_compat_syscall() is true for x32, this would mean we end up here
even if it is a x32 syscall.
But, wouldn't it be better to use in_x32_syscall() here since there is
no timeval any more?
Thanks,
Deepa
This is a variation of the problem we are trying to solve for
the other architectures in your patch set:
On x32, the kernel uses produces a structure with the 64-bit
layout, using __u64 tv_sec, to match the current user space
that has 64-bit __kernel_ulong_t and 64-bit time_t, but
in_compat_syscall() also returns 'true' here, as this is
mostly a 32-bit ABI (time_t being one of the exceptions).
Yes, I missed this.
in_compat_syscall() is true for x32, this would mean we end up here
even if it is a x32 syscall.
But, wouldn't it be better to use in_x32_syscall() here since there is
no timeval any more?
We have to distinguish four cases on x86:
- native 32-bit, input_event with 32-bit time_t
- compat 32-bit, input_event_compat with 32-bit time_t
- native 64-bit, input_event with 64-bit time_t
- compat x32, input_event with 64-bit time_t
The first three can happen on other architectures too,
the last one is x86 specific. There are probably other ways
to express the condition above, but I can't think of one
that is better than the one we have today.
Arnd
This is a variation of the problem we are trying to solve for
the other architectures in your patch set:
On x32, the kernel uses produces a structure with the 64-bit
layout, using __u64 tv_sec, to match the current user space
that has 64-bit __kernel_ulong_t and 64-bit time_t, but
in_compat_syscall() also returns 'true' here, as this is
mostly a 32-bit ABI (time_t being one of the exceptions).
Yes, I missed this.
in_compat_syscall() is true for x32, this would mean we end up here
even if it is a x32 syscall.
But, wouldn't it be better to use in_x32_syscall() here since there is
no timeval any more?
We have to distinguish four cases on x86:
- native 32-bit, input_event with 32-bit time_t
- compat 32-bit, input_event_compat with 32-bit time_t
- native 64-bit, input_event with 64-bit time_t
- compat x32, input_event with 64-bit time_t
The first three can happen on other architectures too,
the last one is x86 specific. There are probably other ways
to express the condition above, but I can't think of one
that is better than the one we have today.
Can we detect if given task is compat x32, like we do for compat
64/32? Or entire userspace has to be x32?
Thanks.
--
Dmitry
I think the COMPAT_USE_64BIT_TIME check has to stay here,
it's needed for x32 mode on x86-64.
We have to distinguish four cases on x86:
- native 32-bit, input_event with 32-bit time_t
- compat 32-bit, input_event_compat with 32-bit time_t
- native 64-bit, input_event with 64-bit time_t
- compat x32, input_event with 64-bit time_t
The first three can happen on other architectures too,
the last one is x86 specific. There are probably other ways
to express the condition above, but I can't think of one
that is better than the one we have today.
Can we detect if given task is compat x32, like we do for compat
64/32? Or entire userspace has to be x32?
Yes, this works fine per task, with the definition of COMPAT_USE_64BIT_TIME
that is hardcoded to zero everywhere except on x86 where it is
#define COMPAT_USE_64BIT_TIME \
(!!(task_pt_regs(current)->orig_ax & __X32_SYSCALL_BIT))
This is unrelated to the patch in question, the existing code
is correct as long as we don't change the logic and just
replace input_event with raw_input_event (or __kernel_input_event
or whichever you prefer).
Arnd
I think we should do those two things completely independently.
We need to do something now to preserve the current interfaces
for the glibc changes that are coming soon [1], and Deepa's
patches do that (though I now realize the changelog doesn't
mention the requirement).
I'll update the changelog in the next version of the series along with
the task check for x32 mode.
An overhaul of the input_event handling with a new modern
but incompatible format may or may not be a good idea, but
this should be decided independently.
Just to clarify, we are going with the plan that Arnd suggested:
leaving the overhaul of the input event protocol alone and proceeding
with the series according to suggested changes.
Are we in agreement over this?
-Deepa
ah, right. that would do it. input-tools@ discarded all posts by nonmembers
(guess that explains why we didn't get much spam :)
I changed that over now, please re-send to the list, thanks.
Cheers,
Peter