* Re: [PATCH v4 0/4] Make input drivers y2038 safe
From: Peter Hutterer @ 2017-12-14 5:33 UTC (permalink / raw)
To: Deepa Dinamani; +Cc: dmitry.torokhov, linux-input, linux-kernel, arnd, y2038
In-Reply-To: <20171207181306.5623-1-deepa.kernel@gmail.com>
On Thu, Dec 07, 2017 at 10:13:02AM -0800, Deepa Dinamani wrote:
> 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 series is also a necessary update as glibc is set to provide
> 64 bit time_t support for 32 bit binaries. glibc plan is detailed
> at https://sourceware.org/glibc/wiki/Y2038ProofnessDesign .
>
> The series is a result of discussions with Arnd Bergmann and
> Dmitry Torokhov at last Plumbers.
>
> 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 design also updates the format of the input events read/ written
> to the device nodes. This breaks 32 bit interface to the input
> events at compile time as preferred by the maintainer.
>
> The userspace library changes to libevdev, libuinput and mtdev
> will be posted to the respective mailing groups for review.
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Cheers,
Peter
> Changes from v3:
> * Updated uinput to support monotonic time only
> * Addressed review comments
> Changes from v2:
> * Updated the design to break 32 bit interfaces at compile time.
> Changes from v1:
> * Updated changes according to review comments.
> * Posted userspace library changes that go along with the series.
>
> Deepa Dinamani (4):
> uinput: Use monotonic times for uinput timestamps.
> input: evdev: Replace timeval with timespec64
> input: Deprecate real timestamps beyond year 2106
> input: serio: Replace timeval by timespec64
>
> drivers/input/evdev.c | 43 +++++++++++++++++++++++++---------------
> drivers/input/input-compat.c | 11 +++++-----
> drivers/input/input-compat.h | 3 ++-
> drivers/input/misc/uinput.c | 5 ++++-
> 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/uapi/linux/input.h | 12 ++++++++++-
> 10 files changed, 88 insertions(+), 62 deletions(-)
>
>
> base-commit: b0a84f19a5161418d4360cd57603e94ed489915e
> --
> 2.14.1
>
^ permalink raw reply
* [PATCH 1/2] input - leds: do not iterate over non initialized leds
From: Benjamin Tissoires @ 2017-12-14 13:25 UTC (permalink / raw)
To: Dmitry Torokhov, Samuel Thibault, Peter Hutterer
Cc: linux-input, linux-kernel, Benjamin Tissoires, stable
In-Reply-To: <20171214132522.20346-1-benjamin.tissoires@redhat.com>
We only instantiate the led classes if there is a definition in
input_led_info[].
However, the max for EV_LED is bigger than the values filled in this
array, and there are some holes in it.
In .connect(), we check for these holes, but in leds_init_work() we do
not, leading to some nice kernel oopses.
Found by running https://github.com/whot/fuzzydevice
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/input/input-leds.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/input/input-leds.c b/drivers/input/input-leds.c
index 83d930f7396a..c86eb3d648bf 100644
--- a/drivers/input/input-leds.c
+++ b/drivers/input/input-leds.c
@@ -94,6 +94,9 @@ static void leds_init_work(struct work_struct *work)
int led_no = 0;
for_each_set_bit(led_code, leds->handle.dev->ledbit, LED_CNT) {
+ if (!input_led_info[led_code].name)
+ continue;
+
led = &leds->leds[led_no];
down_read(&led->cdev.trigger_lock);
--
2.14.3
^ permalink raw reply related
* [PATCH 2/2] input - leds: fix input_led_disconnect path
From: Benjamin Tissoires @ 2017-12-14 13:25 UTC (permalink / raw)
To: Dmitry Torokhov, Samuel Thibault, Peter Hutterer
Cc: linux-input, linux-kernel, Benjamin Tissoires, stable
In-Reply-To: <20171214132522.20346-1-benjamin.tissoires@redhat.com>
Before unregistering the led classes, we have to be sure there is no
more events in the input pipeline.
Closing the input node before removing the led classes flushes the
pipeline and this prevents segfaults.
Found with https://github.com/whot/fuzzydevice
Link: https://bugzilla.kernel.org/show_bug.cgi?id=197679
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/input/input-leds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/input-leds.c b/drivers/input/input-leds.c
index c86eb3d648bf..8aefcc186a02 100644
--- a/drivers/input/input-leds.c
+++ b/drivers/input/input-leds.c
@@ -211,6 +211,7 @@ static void input_leds_disconnect(struct input_handle *handle)
int i;
cancel_delayed_work_sync(&leds->init_work);
+ input_close_device(handle);
for (i = 0; i < leds->num_leds; i++) {
struct input_led *led = &leds->leds[i];
@@ -219,7 +220,6 @@ static void input_leds_disconnect(struct input_handle *handle)
kfree(led->cdev.name);
}
- input_close_device(handle);
input_unregister_handle(handle);
kfree(leds);
--
2.14.3
^ permalink raw reply related
* [PATCH 0/2] input - leds: fix bugs found by fuzzing
From: Benjamin Tissoires @ 2017-12-14 13:25 UTC (permalink / raw)
To: Dmitry Torokhov, Samuel Thibault, Peter Hutterer
Cc: linux-input, linux-kernel, Benjamin Tissoires
Hi,
Peter wrote a fuzzing uinput program[1] to check on libinput,
and the result is that the kernel fails more often than
libinput :)
These 2 patches allow to fix the early failures.
I marked them as stable as I believe eventhough not many
people discovered those and reported them, they should
still be fixed in current kernels.
The fuzzing process still manages to crash the kernel,
bu I have the feeling those crashes are now related
to some races between other userspace process that attempt
to handle the spurious events injected in those random
devices. For instance, the KEY_BLUETOOTH or RF_KILL seem
to manage to mess up my network driver.
Cheers,
Benjamin
[1] https://github.com/whot/fuzzydevice
Benjamin Tissoires (2):
input - leds: do not iterate over non initialized leds
input - leds: fix input_led_disconnect path
drivers/input/input-leds.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--
2.14.3
^ permalink raw reply
* Re: [Y2038] [PATCH v4 1/4] uinput: Use monotonic times for uinput timestamps.
From: Ben Hutchings @ 2017-12-14 21:17 UTC (permalink / raw)
To: Deepa Dinamani, dmitry.torokhov, linux-input, linux-kernel
Cc: y2038, peter.hutterer, arnd
In-Reply-To: <20171207181306.5623-2-deepa.kernel@gmail.com>
On Thu, 2017-12-07 at 10:13 -0800, Deepa Dinamani wrote:
> 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.
>
> The patch switches the timestamps to use monotonic time
> from realtime time. This is assuming no one is using
> absolute times from these timestamps.
Why is this change not opt-in, as for evdev? I assume there were
compatibility reasons for not changing evdev's clock by default, so I
would expect them to apply to uinput as well. (But I'm also prepared
to believe that user-space is now generally compatible with and would
prefer monotonic time from all input devices.)
Ben.
> The structure to maintain input events will be changed
> in a different patch.
>
> Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
> ---
> drivers/input/misc/uinput.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
> index 39ddd9a73feb..d521aecbc078 100644
> --- a/drivers/input/misc/uinput.c
> +++ b/drivers/input/misc/uinput.c
> @@ -84,11 +84,14 @@ static int uinput_dev_event(struct input_dev *dev,
> > unsigned int type, unsigned int code, int value)
> {
> struct uinput_device *udev = input_get_drvdata(dev);
> + struct timespec64 ts;
>
> 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);
> + ktime_get_ts64(&ts);
> + 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);
--
Ben Hutchings
Software Developer, Codethink Ltd.
^ permalink raw reply
* Re: [Y2038] [PATCH v4 1/4] uinput: Use monotonic times for uinput timestamps.
From: Ben Hutchings @ 2017-12-14 21:18 UTC (permalink / raw)
To: Deepa Dinamani, dmitry.torokhov, linux-input, linux-kernel
Cc: y2038, peter.hutterer, arnd
In-Reply-To: <1513286249.18523.280.camel@codethink.co.uk>
On Thu, 2017-12-14 at 21:17 +0000, Ben Hutchings wrote:
> On Thu, 2017-12-07 at 10:13 -0800, Deepa Dinamani wrote:
> > 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.
> >
> > The patch switches the timestamps to use monotonic time
> > from realtime time. This is assuming no one is using
> > absolute times from these timestamps.
>
> Why is this change not opt-in, as for evdev? I assume there were
> compatibility reasons for not changing evdev's clock by default, so I
> would expect them to apply to uinput as well. (But I'm also prepared
> to believe that user-space is now generally compatible with and would
> prefer monotonic time from all input devices.)
Never mind, I've gone back and seen Arnd's comments about compatibility
on v3. It might be worth copying those into the commit message though.
Ben.
> Ben.
>
> > The structure to maintain input events will be changed
> > in a different patch.
> >
> > Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
> > ---
> > drivers/input/misc/uinput.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/input/misc/uinput.c
> > b/drivers/input/misc/uinput.c
> > index 39ddd9a73feb..d521aecbc078 100644
> > --- a/drivers/input/misc/uinput.c
> > +++ b/drivers/input/misc/uinput.c
> > @@ -84,11 +84,14 @@ static int uinput_dev_event(struct input_dev
> > *dev,
> > > unsigned int type, unsigned int
> > > code, int value)
> >
> > {
> > struct uinput_device *udev =
> > input_get_drvdata(dev);
> > + struct timespec64 ts;
> >
> > 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);
> > + ktime_get_ts64(&ts);
> > + 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);
--
Ben Hutchings
Software Developer, Codethink Ltd.
^ permalink raw reply
* Re: [Y2038] [PATCH v4 1/4] uinput: Use monotonic times for uinput timestamps.
From: Deepa Dinamani @ 2017-12-14 21:44 UTC (permalink / raw)
To: Ben Hutchings
Cc: Dmitry Torokhov, open list:HID CORE LAYER,
Linux Kernel Mailing List, y2038 Mailman List, Peter Hutterer,
Arnd Bergmann
In-Reply-To: <1513286332.18523.281.camel@codethink.co.uk>
On Thu, Dec 14, 2017 at 1:18 PM, Ben Hutchings
<ben.hutchings@codethink.co.uk> wrote:
> On Thu, 2017-12-14 at 21:17 +0000, Ben Hutchings wrote:
>> On Thu, 2017-12-07 at 10:13 -0800, Deepa Dinamani wrote:
>> > 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.
>> >
>> > The patch switches the timestamps to use monotonic time
>> > from realtime time. This is assuming no one is using
>> > absolute times from these timestamps.
>>
>> Why is this change not opt-in, as for evdev? I assume there were
>> compatibility reasons for not changing evdev's clock by default, so I
>> would expect them to apply to uinput as well. (But I'm also prepared
>> to believe that user-space is now generally compatible with and would
>> prefer monotonic time from all input devices.)
>
> Never mind, I've gone back and seen Arnd's comments about compatibility
> on v3. It might be worth copying those into the commit message though.
Commit message already talks about this assumption?:
The patch switches the timestamps to use monotonic time
from realtime time. This is assuming no one is using
absolute times from these timestamps.
-Deepa
^ permalink raw reply
* Re: [Y2038] [PATCH v4 4/4] input: serio: Replace timeval by timespec64
From: Ben Hutchings @ 2017-12-14 21:45 UTC (permalink / raw)
To: Deepa Dinamani, dmitry.torokhov, linux-input, linux-kernel
Cc: y2038, peter.hutterer, arnd
In-Reply-To: <20171207181306.5623-5-deepa.kernel@gmail.com>
On Thu, 2017-12-07 at 10:13 -0800, Deepa Dinamani wrote:
> 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.
[...]
> --- a/drivers/input/serio/hil_mlc.c
> +++ b/drivers/input/serio/hil_mlc.c
[...]
> @@ -466,7 +466,7 @@ static const struct hilse_node hil_mlc_se[HILSEN_END] = {
> FUNC(hilse_init_lcv, 0, HILSEN_NEXT, HILSEN_SLEEP, 0)
>
> /* 1 HILSEN_RESTART */
> - FUNC(hilse_inc_lcv, 10, HILSEN_NEXT, HILSEN_START, 0)
> + FUNC(hilse_inc_lcv, 10000, HILSEN_NEXT, HILSEN_START, 0)
[...]
The second macro argument here ends up as the second argument to
hilse_inc_lcv() which appears to limit the number of retries, not a
time limit. So I don't think the value here (or wherever else
hilse_inc_lcv is referenced) should be changed.
The EXPECT, EXPECT_LAST etc. macros take a timeout ('to' parameter)
which is then assigned to hil_mlc::intimeout, so it seems that those
*should* be scaled up, but this patch doesn't do that. It also doesn't
change the type of hil_mlc::intimeout (suseconds_t implying units of
microseconds) or the comment on hilse_node::arg.
Alternately, it might be safer to keep all the timeouts in units of
microseconds.
Ben.
--
Ben Hutchings
Software Developer, Codethink Ltd.
^ permalink raw reply
* Re: [Y2038] [PATCH v4 1/4] uinput: Use monotonic times for uinput timestamps.
From: Ben Hutchings @ 2017-12-14 21:53 UTC (permalink / raw)
To: Deepa Dinamani
Cc: Dmitry Torokhov, open list:HID CORE LAYER,
Linux Kernel Mailing List, y2038 Mailman List, Peter Hutterer,
Arnd Bergmann
In-Reply-To: <CABeXuvpGRtp2fR3yW-eDyCOYpWfLReNytpew7kXD0xOxTEnZZw@mail.gmail.com>
On Thu, 2017-12-14 at 13:44 -0800, Deepa Dinamani wrote:
> On Thu, Dec 14, 2017 at 1:18 PM, Ben Hutchings
> > <ben.hutchings@codethink.co.uk> wrote:
> > On Thu, 2017-12-14 at 21:17 +0000, Ben Hutchings wrote:
> > > On Thu, 2017-12-07 at 10:13 -0800, Deepa Dinamani wrote:
> > > > 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.
> > > >
> > > > The patch switches the timestamps to use monotonic time
> > > > from realtime time. This is assuming no one is using
> > > > absolute times from these timestamps.
> > >
> > > Why is this change not opt-in, as for evdev? I assume there were
> > > compatibility reasons for not changing evdev's clock by default, so I
> > > would expect them to apply to uinput as well. (But I'm also prepared
> > > to believe that user-space is now generally compatible with and would
> > > prefer monotonic time from all input devices.)
> >
> > Never mind, I've gone back and seen Arnd's comments about compatibility
> > on v3. It might be worth copying those into the commit message though.
>
> Commit message already talks about this assumption?:
>
> The patch switches the timestamps to use monotonic time
> from realtime time. This is assuming no one is using
> absolute times from these timestamps.
Yes, but Arnd did a bit of code research to check that assumption.
A commit message that says "we checked and it appears that no user-
space depends on this" looks better than "I assume that no user-space
depends on this".
Ben.
--
Ben Hutchings
Software Developer, Codethink Ltd.
^ permalink raw reply
* Re: [Y2038] [PATCH v4 1/4] uinput: Use monotonic times for uinput timestamps.
From: Deepa Dinamani @ 2017-12-14 22:07 UTC (permalink / raw)
To: Ben Hutchings
Cc: Dmitry Torokhov, open list:HID CORE LAYER,
Linux Kernel Mailing List, y2038 Mailman List, Peter Hutterer,
Arnd Bergmann
In-Reply-To: <1513288412.18523.285.camel@codethink.co.uk>
On Thu, Dec 14, 2017 at 1:53 PM, Ben Hutchings
<ben.hutchings@codethink.co.uk> wrote:
> On Thu, 2017-12-14 at 13:44 -0800, Deepa Dinamani wrote:
>> On Thu, Dec 14, 2017 at 1:18 PM, Ben Hutchings
>> > <ben.hutchings@codethink.co.uk> wrote:
>> > On Thu, 2017-12-14 at 21:17 +0000, Ben Hutchings wrote:
>> > > On Thu, 2017-12-07 at 10:13 -0800, Deepa Dinamani wrote:
>> > > > 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.
>> > > >
>> > > > The patch switches the timestamps to use monotonic time
>> > > > from realtime time. This is assuming no one is using
>> > > > absolute times from these timestamps.
>> > >
>> > > Why is this change not opt-in, as for evdev? I assume there were
>> > > compatibility reasons for not changing evdev's clock by default, so I
>> > > would expect them to apply to uinput as well. (But I'm also prepared
>> > > to believe that user-space is now generally compatible with and would
>> > > prefer monotonic time from all input devices.)
>> >
>> > Never mind, I've gone back and seen Arnd's comments about compatibility
>> > on v3. It might be worth copying those into the commit message though.
>>
>> Commit message already talks about this assumption?:
>>
>> The patch switches the timestamps to use monotonic time
>> from realtime time. This is assuming no one is using
>> absolute times from these timestamps.
>
> Yes, but Arnd did a bit of code research to check that assumption.
> A commit message that says "we checked and it appears that no user-
> space depends on this" looks better than "I assume that no user-space
> depends on this".
The fact is we do not know all the places this is used. Arnd happened
to find an instance. This is why Dmitry suggested that we will provide
a ioctl or something if someone complains.
It is not my assumption. It is the assumption that the patch is based
on. This is to call people's attention to the fact that this is
controversial. And, if they do not agree with the assumption, they
should complain.
So it does not matter we found an instance where the assumption is true.
-Deepa
^ permalink raw reply
* Re: [PATCH 0/2] input - leds: fix bugs found by fuzzing
From: Samuel Thibault @ 2017-12-15 0:16 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Dmitry Torokhov, Peter Hutterer, linux-input, linux-kernel
In-Reply-To: <20171214132522.20346-1-benjamin.tissoires@redhat.com>
Hello,
Benjamin Tissoires, on jeu. 14 déc. 2017 14:25:20 +0100, wrote:
> I marked them as stable as I believe eventhough not many
> people discovered those and reported them, they should
> still be fixed in current kernels.
Well, the quoted source lines are not in any stable tree, I don't even
find them in the mainline tree. Where do these lines come from?
Samuel
^ permalink raw reply
* Re: [PATCH 2/2] input - leds: fix input_led_disconnect path
From: Samuel Thibault @ 2017-12-15 0:19 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Dmitry Torokhov, Peter Hutterer, linux-input, linux-kernel,
stable
In-Reply-To: <20171214132522.20346-3-benjamin.tissoires@redhat.com>
Benjamin Tissoires, on jeu. 14 déc. 2017 14:25:22 +0100, wrote:
> Before unregistering the led classes, we have to be sure there is no
> more events in the input pipeline.
> Closing the input node before removing the led classes flushes the
> pipeline and this prevents segfaults.
>
> Found with https://github.com/whot/fuzzydevice
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=197679
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
input_close_device does run synchronize_rcu() which we seem to have to
process before freeing the rest indeed. Thus,
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
(though AFAIK it doesn't apply on the mainline tree)
> ---
> drivers/input/input-leds.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/input-leds.c b/drivers/input/input-leds.c
> index c86eb3d648bf..8aefcc186a02 100644
> --- a/drivers/input/input-leds.c
> +++ b/drivers/input/input-leds.c
> @@ -211,6 +211,7 @@ static void input_leds_disconnect(struct input_handle *handle)
> int i;
>
> cancel_delayed_work_sync(&leds->init_work);
> + input_close_device(handle);
>
> for (i = 0; i < leds->num_leds; i++) {
> struct input_led *led = &leds->leds[i];
> @@ -219,7 +220,6 @@ static void input_leds_disconnect(struct input_handle *handle)
> kfree(led->cdev.name);
> }
>
> - input_close_device(handle);
> input_unregister_handle(handle);
>
> kfree(leds);
> --
> 2.14.3
>
^ permalink raw reply
* Re: [PATCH] bcm5974: report ABS_MT_PRESSURE
From: Ryan Hendrickson @ 2017-12-15 1:37 UTC (permalink / raw)
To: linux-input; +Cc: Henrik Rydberg
In-Reply-To: <alpine.LNX.2.21.1712011208150.14154@adam>
[-- Attachment #1: Type: text/plain, Size: 2996 bytes --]
Hi, gentle ping? No rush on the review but it would be nice to know if I
followed the right submission procedure and wasn't mistaken for a spammer.
At 2017-12-01 12:13-0500, Ryan Hendrickson <ryan.hendrickson@alum.mit.edu> sent:
> Report ABS_MT_PRESSURE in the bcm5974 driver with the same data used for
> ABS_PRESSURE.
>
> Some touchpad improvements in recent versions of libinput, such as
> pressure-based palm detection, will only work if ABS_MT_PRESSURE is
> reported.
>
> Signed-off-by: Ryan Hendrickson <ryan.hendrickson@alum.mit.edu>
>
> ---
>
> Please treat all of this with an extra grain of salt; this is my first real
> foray into both evdev/libinput internals and kernel development. That said,
> I have been running this patch on my daily-use MacBookPro5,1 for several
> months, so I have reason to believe it's stable. It might not be the
> ‘right’ way to do this though; I mostly just copied the corresponding code
> for ABS_PRESSURE, which from this[1] blog post I've inferred should have
> the same values and range.
>
> [1]: http://who-t.blogspot.com/2016/09/understanding-evdev.html
>
> Patch was originally submitted as bug 197909[2], which can be closed if
> this is accepted.
>
> [2]: https://bugzilla.kernel.org/show_bug.cgi?id=197909
>
> --- linux-4.13/drivers/input/mouse/bcm5974.c.orig 2017-12-01
> 11:36:35.258890243 -0500
> +++ linux-4.13/drivers/input/mouse/bcm5974.c 2017-12-01 11:48:55.187342210
> -0500
> @@ -548,6 +548,8 @@ static void setup_events_to_report(struc
> set_abs(input_dev, ABS_MT_POSITION_X, &cfg->x);
> set_abs(input_dev, ABS_MT_POSITION_Y, &cfg->y);
>
> + set_abs(input_dev, ABS_MT_PRESSURE, &cfg->p);
> +
> __set_bit(EV_KEY, input_dev->evbit);
> __set_bit(BTN_LEFT, input_dev->keybit);
>
> @@ -575,10 +577,14 @@ static int report_bt_state(struct bcm597
> return 0;
> }
>
> -static void report_finger_data(struct input_dev *input, int slot,
> +static void report_finger_data(struct input_dev *input,
> + const struct bcm5974_config *cfg,
> + int slot,
> const struct input_mt_pos *pos,
> const struct tp_finger *f)
> {
> + int abs_p;
> +
> input_mt_slot(input, slot);
> input_mt_report_slot_state(input, MT_TOOL_FINGER, true);
>
> @@ -594,6 +600,9 @@ static void report_finger_data(struct in
> MAX_FINGER_ORIENTATION - raw2int(f->orientation));
> input_report_abs(input, ABS_MT_POSITION_X, pos->x);
> input_report_abs(input, ABS_MT_POSITION_Y, pos->y);
> +
> + abs_p = clamp_val(256 * raw2int(f->touch_major) / cfg->p.max, 0,
> 255);
> + input_report_abs(input, ABS_MT_PRESSURE, abs_p);
> }
>
> static void report_synaptics_data(struct input_dev *input,
> @@ -640,7 +649,7 @@ static int report_tp_state(struct bcm597
> input_mt_assign_slots(input, dev->slots, dev->pos, n, 0);
>
> for (i = 0; i < n; i++)
> - report_finger_data(input, dev->slots[i],
> + report_finger_data(input, c, dev->slots[i],
> &dev->pos[i], dev->index[i]);
>
> input_mt_sync_frame(input);
>
^ permalink raw reply
* Re: [PATCH 0/2] input - leds: fix bugs found by fuzzing
From: Benjamin Tissoires @ 2017-12-15 8:04 UTC (permalink / raw)
To: Samuel Thibault, Benjamin Tissoires, Dmitry Torokhov,
Peter Hutterer, linux-input, linux-kernel
In-Reply-To: <20171215001615.tmcbq4v6fcum2ngj@var.youpi.perso.aquilenet.fr>
On Fri, Dec 15, 2017 at 1:16 AM, Samuel Thibault
<samuel.thibault@ens-lyon.org> wrote:
> Hello,
>
> Benjamin Tissoires, on jeu. 14 déc. 2017 14:25:20 +0100, wrote:
>> I marked them as stable as I believe eventhough not many
>> people discovered those and reported them, they should
>> still be fixed in current kernels.
>
> Well, the quoted source lines are not in any stable tree, I don't even
> find them in the mainline tree. Where do these lines come from?
Oops, indeed, the patch 1/2 fixes a local commit I wrote to fix the
LED not being updated after the connect, that has already been
rejected upstream. (FWIW, it was
https://patchwork.kernel.org/patch/9542397/)
Dmitry, please disregard 1/2 and only have a look at 2/2.
Cheers,
Benjamin
>
> Samuel
^ permalink raw reply
* Re: [PATCH 2/2] input - leds: fix input_led_disconnect path
From: Dmitry Torokhov @ 2017-12-16 0:48 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Samuel Thibault, Peter Hutterer, linux-input, linux-kernel,
stable
In-Reply-To: <20171214132522.20346-3-benjamin.tissoires@redhat.com>
Hi Benjamin,
On Thu, Dec 14, 2017 at 02:25:22PM +0100, Benjamin Tissoires wrote:
> Before unregistering the led classes, we have to be sure there is no
> more events in the input pipeline.
> Closing the input node before removing the led classes flushes the
> pipeline and this prevents segfaults.
I do not think this actually the issue. input_leds_event() is an empty
stub, it does not really do anything with events it receives form input
core, and it does not reference the led structures. The way input leds
work is that input driver owns the hardware led and is responsible for
communicating with it. The LED subsystem is a secondary interface,
requests coming from /sys/class/led/... are being forwarded to the input
core and then to the input hardware driver by the way of:
input_leds_brightness_set() ->
input_inject_event() ->
input_handle_event()->
disposition & INPUT_PASS_TO_DEVICE
dev->event() (in atkbd or hid-input)
actual control of LED
I do not see how stopping event flow from input core to input-leds would
help here.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] input: silead: add Chuwi Hi8 support
From: Hans de Goede @ 2017-12-16 15:15 UTC (permalink / raw)
To: Maruyama Shohei
Cc: linux-input@vger.kernel.org, platform-driver-x86@vger.kernel.org
In-Reply-To: <SLXP216MB0462B59087253DCEFF0811DB9B0B0@SLXP216MB0462.KORP216.PROD.OUTLOOK.COM>
Hi,
On 15-12-17 21:02, Maruyama Shohei wrote:
> This commit add ACPI support for Chuwi Hi8 tablet. On the ACPI table of
> the tablet, GSL1680 is registered as MSSL0001, so the driver does not
> recognize the device. This commit resolve it.
>
> Signed-off-by: Shohei Maruyama <cheat.sc.linux@outlook.com>
Looks good to me:
Acked-by: Hans de Goede <hdegoede@redhat.com>
Regards,
Hans
> ---
> drivers/input/touchscreen/silead.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/input/touchscreen/silead.c b/drivers/input/touchscreen/silead.c
> index 0dbcf105f7db..531f22891462 100644
> --- a/drivers/input/touchscreen/silead.c
> +++ b/drivers/input/touchscreen/silead.c
> @@ -578,6 +578,7 @@ static const struct acpi_device_id silead_ts_acpi_match[] = {
> { "GSL3675", 0 },
> { "GSL3692", 0 },
> { "MSSL1680", 0 },
> + { "MSSL0001", 0 },
> { }
> };
> MODULE_DEVICE_TABLE(acpi, silead_ts_acpi_match);
>
^ permalink raw reply
* Re: [Y2038] [PATCH v4 4/4] input: serio: Replace timeval by timespec64
From: Deepa Dinamani @ 2017-12-16 21:37 UTC (permalink / raw)
To: Ben Hutchings
Cc: Dmitry Torokhov, open list:HID CORE LAYER,
Linux Kernel Mailing List, y2038 Mailman List, Peter Hutterer,
Arnd Bergmann
In-Reply-To: <1513287928.18523.283.camel@codethink.co.uk>
On Thu, Dec 14, 2017 at 1:45 PM, Ben Hutchings
<ben.hutchings@codethink.co.uk> wrote:
> On Thu, 2017-12-07 at 10:13 -0800, Deepa Dinamani wrote:
>> 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.
> [...]
>> --- a/drivers/input/serio/hil_mlc.c
>> +++ b/drivers/input/serio/hil_mlc.c
> [...]
>> @@ -466,7 +466,7 @@ static const struct hilse_node hil_mlc_se[HILSEN_END] = {
>> FUNC(hilse_init_lcv, 0, HILSEN_NEXT, HILSEN_SLEEP, 0)
>>
>> /* 1 HILSEN_RESTART */
>> - FUNC(hilse_inc_lcv, 10, HILSEN_NEXT, HILSEN_START, 0)
>> + FUNC(hilse_inc_lcv, 10000, HILSEN_NEXT, HILSEN_START, 0)
> [...]
>
> The second macro argument here ends up as the second argument to
> hilse_inc_lcv() which appears to limit the number of retries, not a
> time limit. So I don't think the value here (or wherever else
> hilse_inc_lcv is referenced) should be changed.
I think I misread the code here.
> The EXPECT, EXPECT_LAST etc. macros take a timeout ('to' parameter)
> which is then assigned to hil_mlc::intimeout, so it seems that those
> *should* be scaled up, but this patch doesn't do that. It also doesn't
> change the type of hil_mlc::intimeout (suseconds_t implying units of
> microseconds) or the comment on hilse_node::arg.
Yes, I have overlooked the suseconds_t here. So apart from what you
point out IN() and a few other things should also be fixed.
I will drop this patch and repost the series as Arnd mentioned he
already posted a version of this patch. The series can go in without
it and if we prefer my version here, I can submit the patch alone.
Thanks,
-Deepa
^ permalink raw reply
* [PATCH] input/touchscreen: fix hideep.c build errors
From: Randy Dunlap @ 2017-12-18 1:09 UTC (permalink / raw)
To: linux-input@vger.kernel.org, Dmitry Torokhov
Cc: LKML, kbuild test robot, Anthony Kim
From: Randy Dunlap <rdunlap@infradead.org>
Fix build errors due to missing header file.
Fixes these build errors:
drivers/input//touchscreen/hideep.c: In function 'hideep_power_on':
drivers/input//touchscreen/hideep.c:670:3: error: implicit declaration of function 'gpiod_set_value_cansleep'; did you mean 'gpio_set_value_cansleep'? [-Werror=implicit-function-declaration]
gpiod_set_value_cansleep(ts->reset_gpio, 0);
drivers/input//touchscreen/hideep.c: In function 'hideep_power_off':
drivers/input//touchscreen/hideep.c:688:3: error: implicit declaration of function 'gpiod_set_value'; did you mean 'gpio_set_value'? [-Werror=implicit-function-declaration]
gpiod_set_value(ts->reset_gpio, 1);
drivers/input//touchscreen/hideep.c: In function 'hideep_probe':
drivers/input//touchscreen/hideep.c:1039:19: error: implicit declaration of function 'devm_gpiod_get_optional'; did you mean 'devm_regulator_get_optional'? [-Werror=implicit-function-declaration]
ts->reset_gpio = devm_gpiod_get_optional(&client->dev,
drivers/input//touchscreen/hideep.c:1040:17: error: 'GPIOD_OUT_HIGH' undeclared (first use in this function); did you mean 'GPIOF_INIT_HIGH'?
"reset", GPIOD_OUT_HIGH);
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Anthony Kim <anthony.kim@hideep.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org
---
drivers/input/touchscreen/hideep.c | 1 +
1 file changed, 1 insertion(+)
--- lnx-415-rc3.orig/drivers/input/touchscreen/hideep.c
+++ lnx-415-rc3/drivers/input/touchscreen/hideep.c
@@ -11,6 +11,7 @@
#include <linux/firmware.h>
#include <linux/delay.h>
#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
#include <linux/gpio/machine.h>
#include <linux/i2c.h>
#include <linux/acpi.h>
^ permalink raw reply
* [PATCH v5 2/3] input: evdev: Replace timeval with timespec64
From: Deepa Dinamani @ 2017-12-18 5:18 UTC (permalink / raw)
To: dmitry.torokhov, linux-input, linux-kernel; +Cc: peter.hutterer, arnd, y2038
In-Reply-To: <20171218051844.10193-1-deepa.kernel@gmail.com>
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 <deepa.kernel@gmail.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
---
drivers/input/evdev.c | 37 +++++++++++++++++++++++--------------
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index 0193dd4f0452..3171c4882d80 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -156,15 +156,22 @@ static void __evdev_flush_queue(struct evdev_client *client, unsigned int type)
static void __evdev_queue_syn_dropped(struct evdev_client *client)
{
struct input_event ev;
- ktime_t time;
+ struct timespec64 ts;
- time = client->clk_type == EV_CLK_REAL ?
- ktime_get_real() :
- client->clk_type == EV_CLK_MONO ?
- ktime_get() :
- ktime_get_boottime();
+ switch (client->clk_type) {
+ case EV_CLK_REAL:
+ ktime_get_real_ts64(&ts);
+ break;
+ case EV_CLK_MONO:
+ ktime_get_ts64(&ts);
+ break;
+ case EV_CLK_BOOT:
+ get_monotonic_boottime64(&ts);
+ break;
+ }
- ev.time = ktime_to_timeval(time);
+ ev.time.tv_sec = ts.tv_sec;
+ ev.time.tv_usec = ts.tv_nsec / NSEC_PER_USEC;
ev.type = EV_SYN;
ev.code = SYN_DROPPED;
ev.value = 0;
@@ -257,17 +264,20 @@ static void __pass_event(struct evdev_client *client,
static void evdev_pass_values(struct evdev_client *client,
const struct input_value *vals, unsigned int count,
- ktime_t *ev_time)
+ struct timespec64 *ev_time)
{
struct evdev *evdev = client->evdev;
const struct input_value *v;
struct input_event event;
+ struct timespec64 ts;
bool wakeup = false;
if (client->revoked)
return;
- event.time = ktime_to_timeval(ev_time[client->clk_type]);
+ ts = ev_time[client->clk_type];
+ event.time.tv_sec = ts.tv_sec;
+ event.time.tv_usec = ts.tv_nsec / NSEC_PER_USEC;
/* Interrupts are disabled, just acquire the lock. */
spin_lock(&client->buffer_lock);
@@ -304,12 +314,11 @@ static void evdev_events(struct input_handle *handle,
{
struct evdev *evdev = handle->private;
struct evdev_client *client;
- ktime_t ev_time[EV_CLK_MAX];
+ struct timespec64 ev_time[EV_CLK_MAX];
- ev_time[EV_CLK_MONO] = ktime_get();
- ev_time[EV_CLK_REAL] = ktime_mono_to_real(ev_time[EV_CLK_MONO]);
- ev_time[EV_CLK_BOOT] = ktime_mono_to_any(ev_time[EV_CLK_MONO],
- TK_OFFS_BOOT);
+ ktime_get_ts64(&ev_time[EV_CLK_MONO]);
+ ktime_get_real_ts64(&ev_time[EV_CLK_REAL]);
+ get_monotonic_boottime64(&ev_time[EV_CLK_BOOT]);
rcu_read_lock();
--
2.14.1
^ permalink raw reply related
* [PATCH v5 3/3] input: Deprecate real timestamps beyond year 2106
From: Deepa Dinamani @ 2017-12-18 5:18 UTC (permalink / raw)
To: dmitry.torokhov, linux-input, linux-kernel; +Cc: peter.hutterer, arnd, y2038
In-Reply-To: <20171218051844.10193-1-deepa.kernel@gmail.com>
struct timeval is not y2038 safe.
All usage of timeval in the kernel will be replaced by
y2038 safe structures.
The change is also necessary as glibc is introducing support
for 32 bit applications to use 64 bit time_t. Without this
change, many applications would incorrectly interpret values
in the struct input_event.
More details about glibc at
https://sourceware.org/glibc/wiki/Y2038ProofnessDesign .
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.
The change leaves the representation of struct input_event as is
on 64 bit architectures. But uses 2 unsigned long values on 32 bit
machines to support real timestamps until year 2106.
This intentionally breaks the ABI on 32 bit architectures and
compat handling on 64 bit architectures.
This is as per maintainer's preference to introduce compile time errors
rather than run into runtime incompatibilities.
The change requires any 32 bit userspace utilities reading or writing
from event nodes to update their reading format to match the new
input_event. The changes to the popular libraries will be posted once
we agree on the kernel change.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
---
drivers/input/evdev.c | 14 ++++++++------
drivers/input/input-compat.c | 11 ++++++-----
drivers/input/input-compat.h | 3 ++-
drivers/input/misc/uinput.c | 4 ++--
include/uapi/linux/input.h | 12 +++++++++++-
5 files changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index 3171c4882d80..7a7fb0d0a227 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -135,7 +135,8 @@ static void __evdev_flush_queue(struct evdev_client *client, unsigned int type)
continue;
} else if (head != i) {
/* move entry to fill the gap */
- client->buffer[head].time = ev->time;
+ client->buffer[head].input_event_sec = ev->input_event_sec;
+ client->buffer[head].input_event_usec = ev->input_event_usec;
client->buffer[head].type = ev->type;
client->buffer[head].code = ev->code;
client->buffer[head].value = ev->value;
@@ -170,8 +171,8 @@ static void __evdev_queue_syn_dropped(struct evdev_client *client)
break;
}
- ev.time.tv_sec = ts.tv_sec;
- ev.time.tv_usec = ts.tv_nsec / NSEC_PER_USEC;
+ ev.input_event_sec = ts.tv_sec;
+ ev.input_event_usec = ts.tv_nsec / NSEC_PER_USEC;
ev.type = EV_SYN;
ev.code = SYN_DROPPED;
ev.value = 0;
@@ -248,7 +249,8 @@ static void __pass_event(struct evdev_client *client,
*/
client->tail = (client->head - 2) & (client->bufsize - 1);
- client->buffer[client->tail].time = event->time;
+ client->buffer[client->tail].input_event_sec = event->input_event_sec;
+ client->buffer[client->tail].input_event_usec = event->input_event_usec;
client->buffer[client->tail].type = EV_SYN;
client->buffer[client->tail].code = SYN_DROPPED;
client->buffer[client->tail].value = 0;
@@ -276,8 +278,8 @@ static void evdev_pass_values(struct evdev_client *client,
return;
ts = ev_time[client->clk_type];
- event.time.tv_sec = ts.tv_sec;
- event.time.tv_usec = ts.tv_nsec / NSEC_PER_USEC;
+ event.input_event_sec = ts.tv_sec;
+ event.input_event_usec = ts.tv_nsec / NSEC_PER_USEC;
/* Interrupts are disabled, just acquire the lock. */
spin_lock(&client->buffer_lock);
diff --git a/drivers/input/input-compat.c b/drivers/input/input-compat.c
index 2186f71c9fe5..419e40b68486 100644
--- a/drivers/input/input-compat.c
+++ b/drivers/input/input-compat.c
@@ -24,14 +24,15 @@ int input_event_from_user(const char __user *buffer,
sizeof(struct input_event_compat)))
return -EFAULT;
- event->time.tv_sec = compat_event.time.tv_sec;
- event->time.tv_usec = compat_event.time.tv_usec;
+ event->input_event_sec = compat_event.sec;
+ event->input_event_usec = compat_event.usec;
event->type = compat_event.type;
event->code = compat_event.code;
event->value = compat_event.value;
} else {
- if (copy_from_user(event, buffer, sizeof(struct input_event)))
+ if (copy_from_user(event, buffer,
+ sizeof(struct input_event)))
return -EFAULT;
}
@@ -44,8 +45,8 @@ int input_event_to_user(char __user *buffer,
if (in_compat_syscall() && !COMPAT_USE_64BIT_TIME) {
struct input_event_compat compat_event;
- compat_event.time.tv_sec = event->time.tv_sec;
- compat_event.time.tv_usec = event->time.tv_usec;
+ compat_event.sec = event->input_event_sec;
+ compat_event.usec = event->input_event_usec;
compat_event.type = event->type;
compat_event.code = event->code;
compat_event.value = event->value;
diff --git a/drivers/input/input-compat.h b/drivers/input/input-compat.h
index 1563160a7af3..08cd755e73fd 100644
--- a/drivers/input/input-compat.h
+++ b/drivers/input/input-compat.h
@@ -18,7 +18,8 @@
#ifdef CONFIG_COMPAT
struct input_event_compat {
- struct compat_timeval time;
+ compat_ulong_t sec;
+ compat_ulong_t usec;
__u16 type;
__u16 code;
__s32 value;
diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index 9251765645d1..03d22fc90a45 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -90,8 +90,8 @@ static int uinput_dev_event(struct input_dev *dev,
udev->buff[udev->head].code = code;
udev->buff[udev->head].value = value;
ktime_get_ts64(&ts);
- udev->buff[udev->head].time.tv_sec = ts.tv_sec;
- udev->buff[udev->head].time.tv_usec = ts.tv_nsec / NSEC_PER_USEC;
+ udev->buff[udev->head].input_event_sec = ts.tv_sec;
+ udev->buff[udev->head].input_event_usec = ts.tv_nsec / NSEC_PER_USEC;
udev->head = (udev->head + 1) % UINPUT_BUFFER_SIZE;
wake_up_interruptible(&udev->waitq);
diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index 8c5a0bf6ee35..9c5105ff5cc6 100644
--- a/include/uapi/linux/input.h
+++ b/include/uapi/linux/input.h
@@ -21,10 +21,20 @@
/*
* The event structure itself
+ * Note that __USE_TIME_BITS64 is defined by libc based on
+ * application's request to use 64 bit time_t.
*/
-
struct input_event {
+#if (__BITS_PER_LONG != 32 || !defined(__USE_TIME_BITS64)) && !defined(__KERNEL)
struct timeval time;
+#define input_event_sec time.tv_sec
+#define input_event_usec time.tv_usec
+#else
+ __kernel_ulong_t __sec;
+ __kernel_ulong_t __usec;
+#define input_event_sec __sec
+#define input_event_usec __usec
+#endif
__u16 type;
__u16 code;
__s32 value;
--
2.14.1
^ permalink raw reply related
* [PATCH v5 0/3] Make input drivers y2038 safe
From: Deepa Dinamani @ 2017-12-18 5:18 UTC (permalink / raw)
To: dmitry.torokhov, linux-input, linux-kernel; +Cc: peter.hutterer, arnd, y2038
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 series is also a necessary update as glibc is set to provide
64 bit time_t support for 32 bit binaries. glibc plan is detailed
at https://sourceware.org/glibc/wiki/Y2038ProofnessDesign .
The series is a result of discussions with Arnd Bergmann and
Dmitry Torokhov at last Plumbers.
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 design also updates the format of the input events read/ written
to the device nodes. This breaks 32 bit interface to the input
events at compile time as preferred by the maintainer.
The userspace library changes to libevdev, libuinput and mtdev
will be posted to the respective mailing groups for review.
Changes from v4:
* Dropped serio hil patch
Changes from v3:
* Updated uinput to support monotonic time only
* Addressed review comments
Changes from v2:
* Updated the design to break 32 bit interfaces at compile time.
Changes from v1:
* Updated changes according to review comments.
* Posted userspace library changes that go along with the series.
Deepa Dinamani (3):
uinput: Use monotonic times for uinput timestamps.
input: evdev: Replace timeval with timespec64
input: Deprecate real timestamps beyond year 2106
drivers/input/evdev.c | 43 +++++++++++++++++++++++++++----------------
drivers/input/input-compat.c | 11 ++++++-----
drivers/input/input-compat.h | 3 ++-
drivers/input/misc/uinput.c | 5 ++++-
include/uapi/linux/input.h | 12 +++++++++++-
5 files changed, 50 insertions(+), 24 deletions(-)
base-commit: 0c1f9d81ac360d8ad31cbfd2bdcf44de8204188e
--
2.14.1
^ permalink raw reply
* [PATCH v5 1/3] uinput: Use monotonic times for uinput timestamps.
From: Deepa Dinamani @ 2017-12-18 5:18 UTC (permalink / raw)
To: dmitry.torokhov, linux-input, linux-kernel; +Cc: peter.hutterer, arnd, y2038
In-Reply-To: <20171218051844.10193-1-deepa.kernel@gmail.com>
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.
The patch switches the timestamps to use monotonic time
from realtime time. This is assuming no one is using
absolute times from these timestamps.
The structure to maintain input events will be changed
in a different patch.
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
---
drivers/input/misc/uinput.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index 91df0df15e68..9251765645d1 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -84,11 +84,14 @@ static int uinput_dev_event(struct input_dev *dev,
unsigned int type, unsigned int code, int value)
{
struct uinput_device *udev = input_get_drvdata(dev);
+ struct timespec64 ts;
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);
+ ktime_get_ts64(&ts);
+ 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);
--
2.14.1
^ permalink raw reply related
* Re: [PATCH] Add touchscreen platform data for the Onda oBook 20 Plus tablet.
From: Andy Shevchenko @ 2017-12-18 12:41 UTC (permalink / raw)
To: Nerijus Baliunas; +Cc: Hans de Goede, linux-input, Platform Driver
In-Reply-To: <20171210220213.19290-1-nerijus@users.sourceforge.net>
On Mon, Dec 11, 2017 at 12:02 AM, Nerijus Baliunas
<nerijus@users.sourceforge.net> wrote:
> Signed-off-by: Nerijus Baliūnas <nerijus@users.sourceforge.net>
Applied to my review and testing queue with massaged title and written
commit message, thanks. Please, don't forget to do it yourself next
time, otherwise it will slow review and promoting.
> ---
> drivers/platform/x86/silead_dmi.c | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/platform/x86/silead_dmi.c b/drivers/platform/x86/silead_dmi.c
> index 266535c2a72f..414293e8c448 100644
> --- a/drivers/platform/x86/silead_dmi.c
> +++ b/drivers/platform/x86/silead_dmi.c
> @@ -171,6 +171,23 @@ static const struct silead_ts_dmi_data digma_citi_e200_data = {
> .properties = digma_citi_e200_props,
> };
>
> +static const struct property_entry onda_obook_20_plus_props[] = {
> + PROPERTY_ENTRY_U32("touchscreen-size-x", 1728),
> + PROPERTY_ENTRY_U32("touchscreen-size-y", 1148),
> + PROPERTY_ENTRY_BOOL("touchscreen-inverted-x"),
> + PROPERTY_ENTRY_BOOL("touchscreen-inverted-y"),
> + PROPERTY_ENTRY_BOOL("touchscreen-swapped-x-y"),
> + PROPERTY_ENTRY_STRING("firmware-name", "gsl3676-onda-obook-20-plus.fw"),
> + PROPERTY_ENTRY_U32("silead,max-fingers", 10),
> + PROPERTY_ENTRY_BOOL("silead,home-button"),
> + { }
> +};
> +
> +static const struct silead_ts_dmi_data onda_obook_20_plus_data = {
> + .acpi_name = "MSSL1680:00",
> + .properties = onda_obook_20_plus_props,
> +};
> +
> static const struct dmi_system_id silead_ts_dmi_table[] = {
> {
> /* CUBE iwork8 Air */
> @@ -271,6 +288,14 @@ static const struct dmi_system_id silead_ts_dmi_table[] = {
> DMI_MATCH(DMI_BOARD_NAME, "Cherry Trail CR"),
> },
> },
> + {
> + /* Onda oBook 20 Plus */
> + .driver_data = (void *)&onda_obook_20_plus_data,
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "ONDA"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "OBOOK 20 PLUS"),
> + },
> + },
> { },
> };
>
> --
> 2.14.3
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] touchscreen: mms114: add support for mms152
From: Simon Shields @ 2017-12-18 12:49 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Simon Shields
MMS152 has no configuration registers, but the packet format used in
interrupts is identical to mms114.
Signed-off-by: Simon Shields <simon-WP75azK+jQYgsBAKwltoeQ@public.gmane.org>
---
.../bindings/input/touchscreen/mms114.txt | 8 ++--
drivers/input/touchscreen/mms114.c | 55 +++++++++++++++++++---
include/linux/platform_data/mms114.h | 6 +++
3 files changed, 58 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/mms114.txt b/Documentation/devicetree/bindings/input/touchscreen/mms114.txt
index 89d4c56c5671..733411020ced 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/mms114.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/mms114.txt
@@ -1,15 +1,15 @@
-* MELFAS MMS114 touchscreen controller
+* MELFAS MMS114/MMS152 touchscreen controller
Required properties:
-- compatible: must be "melfas,mms114"
+- compatible: "melfas,mms114" for MMS114, or "melfas,mms152" for MMS152
- reg: I2C address of the chip
- interrupts: interrupt to which the chip is connected
- x-size: horizontal resolution of touchscreen
- y-size: vertical resolution of touchscreen
Optional properties:
-- contact-threshold:
-- moving-threshold:
+- contact-threshold: only with "melfas,mms114"
+- moving-threshold: only with "melfas,mms114"
- x-invert: invert X axis
- y-invert: invert Y axis
diff --git a/drivers/input/touchscreen/mms114.c b/drivers/input/touchscreen/mms114.c
index e5eeb6311f7d..d01f36442788 100644
--- a/drivers/input/touchscreen/mms114.c
+++ b/drivers/input/touchscreen/mms114.c
@@ -10,6 +10,7 @@
#include <linux/module.h>
#include <linux/delay.h>
#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/i2c.h>
#include <linux/input/mt.h>
#include <linux/interrupt.h>
@@ -33,6 +34,9 @@
#define MMS114_INFOMATION 0x10
#define MMS114_TSP_REV 0xF0
+#define MMS152_FW_REV 0xE1
+#define MMS152_COMPAT_GROUP 0xF2
+
/* Minimum delay time is 50us between stop and start signal of i2c */
#define MMS114_I2C_DELAY 50
@@ -251,12 +255,27 @@ static int mms114_get_version(struct mms114_data *data)
u8 buf[6];
int error;
- error = __mms114_read_reg(data, MMS114_TSP_REV, 6, buf);
- if (error < 0)
- return error;
+ switch (data->pdata->type) {
+ case TYPE_MMS152:
+ error = __mms114_read_reg(data, MMS152_FW_REV, 3, buf);
+ if (error < 0)
+ return error;
+ buf[3] = i2c_smbus_read_byte_data(data->client,
+ MMS152_COMPAT_GROUP);
+ if (buf[3] < 0)
+ return buf[3];
+ dev_info(dev, "TSP FW Rev: bootloader 0x%x / core 0x%x / config 0x%x, Compat group: %c\n",
+ buf[0], buf[1], buf[2], buf[3]);
+ break;
+ case TYPE_MMS114:
+ error = __mms114_read_reg(data, MMS114_TSP_REV, 6, buf);
+ if (error < 0)
+ return error;
- dev_info(dev, "TSP Rev: 0x%x, HW Rev: 0x%x, Firmware Ver: 0x%x\n",
- buf[0], buf[1], buf[3]);
+ dev_info(dev, "TSP Rev: 0x%x, HW Rev: 0x%x, Firmware Ver: 0x%x\n",
+ buf[0], buf[1], buf[3]);
+ break;
+ }
return 0;
}
@@ -271,6 +290,11 @@ static int mms114_setup_regs(struct mms114_data *data)
if (error < 0)
return error;
+ if (data->pdata->type == TYPE_MMS152) {
+ /* MMS152 has no configuration or power on registers */
+ return 0;
+ }
+
error = mms114_set_active(data, true);
if (error < 0)
return error;
@@ -391,6 +415,8 @@ static struct mms114_platform_data *mms114_parse_dt(struct device *dev)
return NULL;
}
+ pdata->type = (enum mms_type)of_device_get_match_data(dev);
+
if (of_property_read_u32(np, "x-size", &pdata->x_size)) {
dev_err(dev, "failed to get x-size property\n");
return NULL;
@@ -411,6 +437,7 @@ static struct mms114_platform_data *mms114_parse_dt(struct device *dev)
if (of_find_property(np, "y-invert", NULL))
pdata->y_invert = true;
+
return pdata;
}
#else
@@ -456,7 +483,15 @@ static int mms114_probe(struct i2c_client *client,
data->input_dev = input_dev;
data->pdata = pdata;
- input_dev->name = "MELFAS MMS114 Touchscreen";
+ switch (pdata->type) {
+ case TYPE_MMS114:
+ input_dev->name = "MELFAS MMS114 Touchscreen";
+ break;
+ case TYPE_MMS152:
+ input_dev->name = "MELFAS MMS152 Touchscreen";
+ break;
+ }
+
input_dev->id.bustype = BUS_I2C;
input_dev->dev.parent = &client->dev;
input_dev->open = mms114_input_open;
@@ -569,7 +604,13 @@ MODULE_DEVICE_TABLE(i2c, mms114_id);
#ifdef CONFIG_OF
static const struct of_device_id mms114_dt_match[] = {
- { .compatible = "melfas,mms114" },
+ {
+ .compatible = "melfas,mms114",
+ .data = (void *)TYPE_MMS114,
+ }, {
+ .compatible = "melfas,mms152",
+ .data = (void *)TYPE_MMS152,
+ },
{ }
};
MODULE_DEVICE_TABLE(of, mms114_dt_match);
diff --git a/include/linux/platform_data/mms114.h b/include/linux/platform_data/mms114.h
index 5722ebfb2738..58e4c463bf0c 100644
--- a/include/linux/platform_data/mms114.h
+++ b/include/linux/platform_data/mms114.h
@@ -10,6 +10,11 @@
#ifndef __LINUX_MMS114_H
#define __LINUX_MMS114_H
+enum mms_type {
+ TYPE_MMS114,
+ TYPE_MMS152,
+};
+
struct mms114_platform_data {
unsigned int x_size;
unsigned int y_size;
@@ -17,6 +22,7 @@ struct mms114_platform_data {
unsigned int moving_threshold;
bool x_invert;
bool y_invert;
+ enum mms_type type;
void (*cfg_pin)(bool);
};
--
2.15.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] touchscreen: mms114: add support for mms152
From: Andi Shyti @ 2017-12-19 6:22 UTC (permalink / raw)
To: Simon Shields; +Cc: Dmitry Torokhov, linux-input, devicetree
In-Reply-To: <20171218124933.1803-1-simon@lineageos.org>
Hi Simon,
> + if (data->pdata->type == TYPE_MMS152) {
> + /* MMS152 has no configuration or power on registers */
> + return 0;
> + }
> +
Please drop the brackets here accorting to the
Documentation/process/coding-style.rst file.
> + pdata->type = (enum mms_type)of_device_get_match_data(dev);
> +
> if (of_property_read_u32(np, "x-size", &pdata->x_size)) {
> dev_err(dev, "failed to get x-size property\n");
> return NULL;
> @@ -411,6 +437,7 @@ static struct mms114_platform_data *mms114_parse_dt(struct device *dev)
> if (of_find_property(np, "y-invert", NULL))
> pdata->y_invert = true;
>
> +
Please do not add extra lines
> return pdata;
> }
> #else
> @@ -456,7 +483,15 @@ static int mms114_probe(struct i2c_client *client,
> data->input_dev = input_dev;
> data->pdata = pdata;
>
> - input_dev->name = "MELFAS MMS114 Touchscreen";
> + switch (pdata->type) {
> + case TYPE_MMS114:
> + input_dev->name = "MELFAS MMS114 Touchscreen";
> + break;
> + case TYPE_MMS152:
> + input_dev->name = "MELFAS MMS152 Touchscreen";
> + break;
> + }
> +
> input_dev->id.bustype = BUS_I2C;
> input_dev->dev.parent = &client->dev;
> input_dev->open = mms114_input_open;
> @@ -569,7 +604,13 @@ MODULE_DEVICE_TABLE(i2c, mms114_id);
>
> #ifdef CONFIG_OF
> static const struct of_device_id mms114_dt_match[] = {
> - { .compatible = "melfas,mms114" },
> + {
> + .compatible = "melfas,mms114",
> + .data = (void *)TYPE_MMS114,
> + }, {
> + .compatible = "melfas,mms152",
> + .data = (void *)TYPE_MMS152,
You are not documenting the new "melfas,mms152" compatible in
Documentation/devicetree/bindings/input/touchscreen/mms114.txt
Andi
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox