Re: [PATCH HID v2 08/11] HID: add per device quirk to force bind to hid-generic
On Tue, Sep 10, 2024 at 11:43:44PM +0900, Benjamin Tissoires wrote:
> We already have the possibility to force not binding to hid-generic and
> rely on a dedicated driver, but we couldn't do the other way around.
>
> This is useful for BPF programs where we are fixing the report descriptor
> and the events, but want to avoid a specialized driver to come after BPF
> which would unwind everything that is done there.
>
> Signed-off-by: Benjamin Tissoires
>
> ---
>
> changes in v2:
> - rely on hdev->quirks for that instead of a new struct for hid_driver
I like this one a lot more than the previous approach, series is
Reviewed-by: Peter Hutterer
although for 01 and 06 this should be taken with a grain of salt :)
Cheers,
Peter
> ---
> drivers/hid/hid-core.c| 5 +++--
> drivers/hid/hid-generic.c | 3 +++
> include/linux/hid.h | 2 ++
> 3 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 37e52759a931..bf63e2819baf 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -2665,9 +2665,10 @@ static bool hid_check_device_match(struct hid_device
> *hdev,
> /*
>* hid-generic implements .match(), so we must be dealing with a
>* different HID driver here, and can simply check if
> - * hid_ignore_special_drivers is set or not.
> + * hid_ignore_special_drivers or HID_QUIRK_IGNORE_SPECIAL_DRIVER
> + * are set or not.
>*/
> - return !hid_ignore_special_drivers;
> + return !hid_ignore_special_drivers && !(hdev->quirks &
> HID_QUIRK_IGNORE_SPECIAL_DRIVER);
> }
>
> static int __hid_device_probe(struct hid_device *hdev, struct hid_driver
> *hdrv)
> diff --git a/drivers/hid/hid-generic.c b/drivers/hid/hid-generic.c
> index f9db991d3c5a..2c1bfffe 100644
> --- a/drivers/hid/hid-generic.c
> +++ b/drivers/hid/hid-generic.c
> @@ -40,6 +40,9 @@ static bool hid_generic_match(struct hid_device *hdev,
> if (ignore_special_driver)
> return true;
>
> + if (hdev->quirks & HID_QUIRK_IGNORE_SPECIAL_DRIVER)
> + return true;
> +
> if (hdev->quirks & HID_QUIRK_HAVE_SPECIAL_DRIVER)
> return false;
>
> diff --git a/include/linux/hid.h b/include/linux/hid.h
> index d41fa18f1e03..b3a9586363c9 100644
> --- a/include/linux/hid.h
> +++ b/include/linux/hid.h
> @@ -359,6 +359,7 @@ struct hid_item {
> * | @HID_QUIRK_NO_OUTPUT_REPORTS_ON_INTR_EP:
> * | @HID_QUIRK_HAVE_SPECIAL_DRIVER:
> * | @HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE:
> + * | @HID_QUIRK_IGNORE_SPECIAL_DRIVER
> * | @HID_QUIRK_FULLSPEED_INTERVAL:
> * | @HID_QUIRK_NO_INIT_REPORTS:
> * | @HID_QUIRK_NO_IGNORE:
> @@ -384,6 +385,7 @@ struct hid_item {
> #define HID_QUIRK_HAVE_SPECIAL_DRIVERBIT(19)
> #define HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE BIT(20)
> #define HID_QUIRK_NOINVERT BIT(21)
> +#define HID_QUIRK_IGNORE_SPECIAL_DRIVER BIT(22)
> #define HID_QUIRK_FULLSPEED_INTERVAL BIT(28)
> #define HID_QUIRK_NO_INIT_REPORTSBIT(29)
> #define HID_QUIRK_NO_IGNORE BIT(30)
>
> --
> 2.46.0
>
Re: [PATCH HID v2 02/11] HID: core: save one kmemdup during .probe()
On Tue, Sep 10, 2024 at 11:43:38PM +0900, Benjamin Tissoires wrote:
> Turns out the first kmemdup is only required for the .report_fixup()
> driver callback. There is no need to do two kmemdup() in a raw in case
typo: "in a row"?
Cheers,
Peter
> .report_fixup() is not present.
>
> Signed-off-by: Benjamin Tissoires
>
> ---
>
> new in v2
> ---
> drivers/hid/hid-core.c | 18 +++---
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index a5f5415571cb..172746a082f9 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -1206,7 +1206,7 @@ int hid_open_report(struct hid_device *device)
> struct hid_item item;
> unsigned int size;
> const __u8 *start;
> - __u8 *buf;
> + __u8 *buf = NULL;
> const __u8 *end;
> const __u8 *next;
> int ret;
> @@ -1227,14 +1227,18 @@ int hid_open_report(struct hid_device *device)
> if (WARN_ON(!start))
> return -ENODEV;
>
> - buf = kmemdup(start, size, GFP_KERNEL);
> - if (buf == NULL)
> - return -ENOMEM;
> + if (device->driver->report_fixup) {
> + /*
> + * device->driver->report_fixup() needs to work
> + * on a copy of our report descriptor so it can
> + * change it.
> + */
> + buf = kmemdup(start, size, GFP_KERNEL);
> + if (buf == NULL)
> + return -ENOMEM;
>
> - if (device->driver->report_fixup)
> start = device->driver->report_fixup(device, buf, &size);
> - else
> - start = buf;
> + }
>
> start = kmemdup(start, size, GFP_KERNEL);
> kfree(buf);
>
> --
> 2.46.0
>
Re: [PATCH v7 3/3] Input: add driver for the Hycon HY46XX touchpanel series
On Wed, Apr 14, 2021 at 10:26:13AM -0700, Dmitry Torokhov wrote: > Hi Giulio, Peter, > > On Wed, Apr 14, 2021 at 01:22:55PM +0200, Giulio Benetti wrote: > > Hi Peter, Dmitry, > > > > On 4/14/21 8:46 AM, Peter Hutterer wrote: > > > On Tue, Apr 13, 2021 at 10:44:07PM -0700, Dmitry Torokhov wrote: > > > > Hi Giulio, > > > > > > > > On Tue, Apr 13, 2021 at 04:44:46PM +0200, Giulio Benetti wrote: > > > > > + > > > > > + input_mt_report_pointer_emulation(tsdata->input, true); > > > > > > > > For touchscreens it does not make much sense to report BTN_DOUBLETAP, > > > > BTN_TRIPLETAP, etc, events (they are really for touchpads), so I changed > > > > this to > > > > > > > > input_mt_report_pointer_emulation(tsdata->input, false); > > > > > > > > to only report ABS_X, ABS_Y, and BTN_TOUCH, and applied. > > > > > > Can you expand on this please, just to make sure I'm not misinterpreting > > > those codes? Those bits are just for how many fingers are down (but > > > without > > > position), dropping those bits means you restrict the device to a pure > > > single-touch screen. Or am I missing something here? > > They are indeed represent number of fingers on the surface. I think I > over-simplified this a bit by saying these events are only for > touchpads, as there is allowance for BTN_TOOL_*TAP in > Documentation/input/multi-touch-protocol.rst for MT devices that may > report more contacts than what they can distinctly track, and it is > not restricted to touchpads (but I believe in reality only used by a > couple of "semi-MT" touchpad drivers). fwiw, almost all touchpads on ps2 use that functionality - they can track 2 touchpoints but *detect* up to 5. There's significant insanity in libinput to deal with that because it is so common :) semi-mt is orthogonal to that, it's the an inability to track two touchpoints correctly (only get top-left and bottom-right, but it's guesswork which finger is in which corner). > What I meant to say that for ST fallback of MT-capable devices we > typically provide BTN_TOOL_*TAP for devices declared as INPUT_MT_POINTER > (which is touchpads) and for INPUT_MT_DIRECT and others we only provide > ABS_X, ABS_Y, ABS_PRESSURE and BTN_TOUCH (see input_mt_sync_frame()), > and I think this driver should follow the suit. ah, right. that makes sense, thanks for the clarification. Cheers, Peter
Re: [PATCH v7 3/3] Input: add driver for the Hycon HY46XX touchpanel series
On Tue, Apr 13, 2021 at 10:44:07PM -0700, Dmitry Torokhov wrote: > Hi Giulio, > > On Tue, Apr 13, 2021 at 04:44:46PM +0200, Giulio Benetti wrote: > > + > > + input_mt_report_pointer_emulation(tsdata->input, true); > > For touchscreens it does not make much sense to report BTN_DOUBLETAP, > BTN_TRIPLETAP, etc, events (they are really for touchpads), so I changed > this to > > input_mt_report_pointer_emulation(tsdata->input, false); > > to only report ABS_X, ABS_Y, and BTN_TOUCH, and applied. Can you expand on this please, just to make sure I'm not misinterpreting those codes? Those bits are just for how many fingers are down (but without position), dropping those bits means you restrict the device to a pure single-touch screen. Or am I missing something here? then again, MT support has been in the kernel for long enough that by now everything should understand it, so there's a certain "meh" factor. Cheers, Peter
Re: [PATCH] HID: hid-input: avoid splitting keyboard, system and consumer controls
On Wed, Jan 13, 2021 at 10:24:13PM -0800, Dmitry Torokhov wrote: > A typical USB keyboard usually splits its keys into several reports: > > - one for the basic alphanumeric keys, modifier keys, F keys, six pack > keys and keypad. This report's application is normally listed as > GenericDesktop.Keyboard > - a GenericDesktop.SystemControl report for the system control keys, such > as power and sleep > - Consumer.ConsumerControl report for multimedia (forward, rewind, > play/pause, mute, etc) and other extended keys. > - additional output, vendor specific, and feature reports > > Splitting each report into a separate input device is wasteful and even > hurts userspace as it makes it harder to determine the true capabilities > (set of available keys) of a keyboard, so let's adjust application > matching to merge system control and consumer control reports with > keyboard report, if one has already been processed. > > Signed-off-by: Dmitry Torokhov Acked-by: Peter Hutterer I think, let's see if there's any fallout from that :) Cheers, Peter
[PATCH] Documentation: input: define ABS_PRESSURE/ABS_MT_PRESSURE resolution as grams
ABS_PRESSURE and ABS_MT_PRESSURE on touch devices usually represent
contact size (as a finger flattens with higher pressure the contact size
increases) and userspace translates the kernel pressure value back into
contact size. For example, libinput has pressure thresholds when a touch is
considered a palm (palm == large contact area -> high pressure). The values
themselves are on an arbitrary scale and device-specific.
On pressurepads however, the pressure axis may represent the real physical
pressure. Pressurepads are touchpads without a hinge but an actual pressure
sensor underneath the device instead, for example the Lenovo Yoga 9i.
A high-enough pressure is converted to a button click by the firmware.
Microsoft does not require a pressure axis to be present, see [1], so as seen
from userspace most pressurepads are identical to clickpads - one button and
INPUT_PROP_BUTTONPAD set.
However, pressurepads that export the pressure axis break userspace because
that axis no longer represents contact size, resulting in inconsistent touch
tracking, e.g. [2]. Userspace needs to know when a pressure axis represents
real pressure and the best way to do so is to define what the resolution
field means. Userspace can then treat data with a pressure resolution as
true pressure.
This patch documents that the pressure resolution is in units/gram. This
allows for fine-grained detail and tops out at roughly ~2000t, enough for the
devices we're dealing with. Grams is not a scientific pressure unit but the
alternative is:
- Pascal: defined as force per area and area is unreliable on many devices and
seems like the wrong option here anyway, especially for devices with a
single pressure sensor only.
- Newton: defined as mass * distance/acceleration and for the purposes of a
pressure axis, the distance is tricky to interpret and we get the data to
calculate acceleration from event timestamps anyway.
For the purposes of touch devices and digitizers, grams seems the best choice
and the easiest to interpret.
Bonus side effect: we can use the existing hwdb infrastructure in userspace to
fix devices that advertise false pressure.
[1]
https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/windows-precision-touchpad-required-hid-top-level-collections#windows-precision-touchpad-input-reports
[2] https://gitlab.freedesktop.org/libinput/libinput/-/issues/562
Signed-off-by: Peter Hutterer
---
Documentation/input/event-codes.rst | 15 +++
Documentation/input/multi-touch-protocol.rst | 4
2 files changed, 19 insertions(+)
diff --git a/Documentation/input/event-codes.rst
b/Documentation/input/event-codes.rst
index b24b5343f5eb..3118fc1c1e26 100644
--- a/Documentation/input/event-codes.rst
+++ b/Documentation/input/event-codes.rst
@@ -236,6 +236,21 @@ A few EV_ABS codes have special meanings:
- Used to describe multitouch input events. Please see
multi-touch-protocol.txt for details.
+* ABS_PRESSURE/ABS_MT_PRESSURE:
+
+ - For touch devices, many devices converted contact size into pressure.
+ A finger flattens with pressure, causing a larger contact area and thus
+ pressure and contact size are directly related. This is not the case
+ for other devices, for example digitizers and touchpads with a true
+ pressure sensor ("pressure pads").
+
+ A device should set the resolution of the axis to indicate whether the
+ pressure is in measurable units. If the resolution is zero, the
+ pressure data is in arbitrary units. If the resolution is nonzero, the
+ pressure data is in units/gram. For example, a value of 10 with a
+ resolution of 1 represents 10 gram, a value of 10 with a resolution on
+ 1000 represents 10 microgram.
+
EV_SW
-
diff --git a/Documentation/input/multi-touch-protocol.rst
b/Documentation/input/multi-touch-protocol.rst
index 307fe22d9668..21c1e6a22888 100644
--- a/Documentation/input/multi-touch-protocol.rst
+++ b/Documentation/input/multi-touch-protocol.rst
@@ -260,6 +260,10 @@ ABS_MT_PRESSURE
of TOUCH and WIDTH for pressure-based devices or any device with a spatial
signal intensity distribution.
+If the resolution is zero, the pressure data is in arbitrary units.
+If the resolution is nonzero, the pressure data is in units/gram. See
+:ref:`input-event-codes` for details.
+
ABS_MT_DISTANCE
The distance, in surface units, between the contact and the surface. Zero
distance means the contact is touching the surface. A positive number means
--
2.29.2
Re: [PATCH 08/15] input: touchscreen: surface3_spi: Remove set but unused variable 'timestamp'
On Fri, Nov 13, 2020 at 08:42:37AM +0100, Benjamin Tissoires wrote:
> On Fri, Nov 13, 2020 at 8:40 AM Dmitry Torokhov
> wrote:
> >
> > On Thu, Nov 12, 2020 at 11:01:57AM +, Lee Jones wrote:
> > > Fixes the following W=1 kernel build warning(s):
> > >
> > > drivers/input/touchscreen/surface3_spi.c: In function
> > > ‘surface3_spi_process_touch’:
> > > drivers/input/touchscreen/surface3_spi.c:97:6: warning: variable
> > > ‘timestamp’ set but not used [-Wunused-but-set-variable]
> > >
> > > Cc: Dmitry Torokhov
> > > Cc: Henrik Rydberg
> > > Cc: Benjamin Tissoires
> > > Cc: linux-in...@vger.kernel.org
> > > Signed-off-by: Lee Jones
> > > ---
> > > drivers/input/touchscreen/surface3_spi.c | 2 --
> > > 1 file changed, 2 deletions(-)
> > >
> > > diff --git a/drivers/input/touchscreen/surface3_spi.c
> > > b/drivers/input/touchscreen/surface3_spi.c
> > > index ce4828b1415a8..72dc4c562a4e1 100644
> > > --- a/drivers/input/touchscreen/surface3_spi.c
> > > +++ b/drivers/input/touchscreen/surface3_spi.c
> > > @@ -94,9 +94,7 @@ static void surface3_spi_report_touch(struct
> > > surface3_ts_data *ts_data,
> > >
> > > static void surface3_spi_process_touch(struct surface3_ts_data *ts_data,
> > > u8 *data)
> > > {
> > > - u16 timestamp;
> > > unsigned int i;
> > > - timestamp = get_unaligned_le16(&data[15]);
> >
> > Benjamin, should we pass timing data on to userspace instead?
>
> Last time I checked, libinput was not using the HW timestamp. So I
> don't mind dropping it.
I'm assuming this would be passed on as MSC_TIMESTAMP?
I never found the time implementing this and I mask MSC_TIMESTAMP on most
devices anyway (except for Dell's i2c touchpads where I need it to work
around a fw bug). so at least from libinput's POV it wouldn't have any
effect either way.
Cheers,
Peter
>
> Not sure if chrome/android uses it.
>
> Cheers,
> Benjamin
>
> >
> > >
> > > for (i = 0; i < 13; i++) {
> > > struct surface3_ts_data_finger *finger;
> > > --
> > > 2.25.1
> > >
> >
> > Thanks.
> >
> > --
> > Dmitry
Re: [PATCH] HID: logitech-hidpp: Add PID for MX Anywhere 2
On Wed, Oct 21, 2020 at 06:56:12AM -0700, Harry Cutts wrote:
> It seems that the PID 0x4072 was missing from the list Logitech gave me
> for this mouse, as I found one with it in the wild (with which I tested
> this patch).
>
> Fixes: 4435ff2f09a2 ("HID: logitech: Enable high-resolution scrolling on
> Logitech mice")
> Signed-off-by: Harry Cutts
Acked-by: Peter Hutterer
we have the same PID for this device in libratbag so there must be some
truth to it ;)
Cheers,
Peter
> ---
>
> drivers/hid/hid-logitech-hidpp.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/hid/hid-logitech-hidpp.c
> b/drivers/hid/hid-logitech-hidpp.c
> index b8b53dc95e86b..730036650f7df 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -3947,6 +3947,7 @@ static const struct hid_device_id hidpp_devices[] = {
> LDJ_DEVICE(0x405e), .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> { /* Mouse Logitech MX Anywhere 2 */
> LDJ_DEVICE(0x404a), .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> + { LDJ_DEVICE(0x4072), .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> { LDJ_DEVICE(0xb013), .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> { LDJ_DEVICE(0xb018), .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> { LDJ_DEVICE(0xb01f), .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> --
> 2.29.0.rc1.297.gfa9743e501-goog
>
Re: INFO: task hung in corrupted (2)
On Thu, Jun 04, 2020 at 01:41:07PM +0200, Jiri Kosina wrote:
> On Tue, 2 Jun 2020, Andrey Konovalov wrote:
>
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit:b0c3ba31 Merge tag 'fsnotify_for_v5.7-rc8' of
> > > git://git.ke..
> > > git tree: upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=14089eee10
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=ce116858301bc2ea
> > > dashboard link:
> > > https://syzkaller.appspot.com/bug?extid=6921abfb75d6fc79c0eb
> > > compiler: clang version 10.0.0
> > > (https://github.com/llvm/llvm-project/
> > > c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
> > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14947d2610
> > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=172726d210
> > >
> > > The bug was bisected to:
> > >
> > > commit f2c2e717642c66f7fe7e5dd69b2e8ff5849f4d10
> > > Author: Andrey Konovalov
> > > Date: Mon Feb 24 16:13:03 2020 +
> > >
> > > usb: gadget: add raw-gadget interface
> > >
> > > bisection log:
> > > https://syzkaller.appspot.com/x/bisect.txt?x=119e470210
> > > final crash:
> > > https://syzkaller.appspot.com/x/report.txt?x=139e470210
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=159e470210
> > >
> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > Reported-by: syzbot+6921abfb75d6fc79c...@syzkaller.appspotmail.com
> > > Fixes: f2c2e717642c ("usb: gadget: add raw-gadget interface")
> > >
> > > INFO: task syz-executor610:7072 blocked for more than 143 seconds.
> > > Not tainted 5.7.0-rc7-syzkaller #0
> > > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > > syz-executor610 D24336 7072 7071 0x80004002
> > > Call Trace:
> > > context_switch kernel/sched/core.c:3367 [inline]
> > > __schedule+0x805/0xc90 kernel/sched/core.c:4083
> > >
> > > Showing all locks held in the system:
> > > 1 lock held by khungtaskd/1134:
> > > #0: 892e85d0 (rcu_read_lock){}-{1:2}, at:
> > > rcu_lock_acquire+0x0/0x30 net/mptcp/pm_netlink.c:860
> > > 1 lock held by in:imklog/6715:
> > > #0: 8880a441e6b0 (&f->f_pos_lock){+.+.}-{3:3}, at:
> > > __fdget_pos+0x25d/0x2f0 fs/file.c:826
> > > 6 locks held by kworker/1:0/7064:
> > > 1 lock held by syz-executor610/7072:
> > > #0: 892eab20 (rcu_state.exp_mutex){+.+.}-{3:3}, at:
> > > exp_funnel_lock kernel/rcu/tree_exp.h:290 [inline]
> > > #0: 892eab20 (rcu_state.exp_mutex){+.+.}-{3:3}, at:
> > > synchronize_rcu_expedited+0x1bd/0x5b0 kernel/rcu/tree_exp.h:856
> > > 4 locks held by systemd-udevd/7099:
> > > #0: 8880a7fdcc70 (&p->lock){+.+.}-{3:3}, at: seq_read+0x60/0xce0
> > > fs/seq_file.c:153
> > > #1: 888096486888 (&of->mutex){+.+.}-{3:3}, at:
> > > kernfs_seq_start+0x50/0x3b0 fs/kernfs/file.c:111
> > > #2: 88809fc0d660 (kn->count#78){.+.+}-{0:0}, at:
> > > kernfs_seq_start+0x6f/0x3b0 fs/kernfs/file.c:112
> > > #3: 8880a1df7218 (&dev->mutex){}-{3:3}, at:
> > > device_lock_interruptible include/linux/device.h:773 [inline]
> > > #3: 8880a1df7218 (&dev->mutex){}-{3:3}, at:
> > > serial_show+0x22/0xa0 drivers/usb/core/sysfs.c:142
> > >
> > > =
> > >
> > > NMI backtrace for cpu 0
> > > CPU: 0 PID: 1134 Comm: khungtaskd Not tainted 5.7.0-rc7-syzkaller #0
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > Google 01/01/2011
> > > Call Trace:
> > > __dump_stack lib/dump_stack.c:77 [inline]
> > > dump_stack+0x1e9/0x30e lib/dump_stack.c:118
> > > nmi_cpu_backtrace+0x9f/0x180 lib/nmi_backtrace.c:101
> > > nmi_trigger_cpumask_backtrace+0x16a/0x280 lib/nmi_backtrace.c:62
> > > check_hung_uninterruptible_tasks kernel/hung_task.c:205 [inline]
> > > watchdog+0xd2a/0xd40 kernel/hung_task.c:289
> > > kthread+0x353/0x380 kernel/kthread.c:268
> > > ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:351
> > > Sending NMI from CPU 0 to CPUs 1:
> > > NMI backtrace for cpu 1
> > > CPU: 1 PID: 7064 Comm: kworker/1:0 Not tainted 5.7.0-rc7-syzkaller #0
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > Google 01/01/2011
> > > Workqueue: usb_hub_wq hub_event
> > > RIP: 0010:__sanitizer_cov_trace_const_cmp4+0x0/0x90 kernel/kcov.c:275
> > > Code: 4c f2 08 48 c1 e0 03 48 83 c8 18 49 89 14 02 4d 89 44 f2 18 49 ff
> > > c1 4d 89 0a c3 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 <4c> 8b 04 24
> > > 65 48 8b 04 25 40 1e 02 00 65 8b 0d 78 96 8e 7e f7 c1
> > > RSP: 0018:c90001676cf0 EFLAGS: 0246
> > > RAX: RBX: RCX: 88809fb9e240
> > > RDX: RSI: RDI:
> > > RBP: 888092d24a04 R08: 86034f3b R09: c900016790cc
> > > R10: 0004 R11: R12: 888092d24a00
> > > R13: R14: dc00 R15
Re: [PATCH] input: API for Setting a Timestamp from a Driver
On Fri, Jul 12, 2019 at 09:23:20AM +0200, Benjamin Tissoires wrote:
> On Fri, Jul 12, 2019 at 8:41 AM Dmitry Torokhov
> wrote:
> >
> > Hi Atif,
> >
> > On Wed, Jul 10, 2019 at 04:04:10PM -0700, Atif Niyaz wrote:
> > > Currently, evdev stamps time with timestamps acquired in
> > > evdev_events. However, this timestamping may not be accurate in terms of
> > > measuring when the actual event happened. This API allows any 3rd party
> > > driver to be able to call input_set_timestamp, and provide a timestamp
> > > that can be utilized in order to provide a more accurate sense of time
> > > for the event
> > >
> > > Signed-off-by: Atif Niyaz
> >
> > This looks OK to me. Benjamin, Peter, any concerns here?
> >
>
> No red flags from me (though Peter is the one using all of this).
>
> Just curious, which drivers do you think will be using this new API?
> I can see that we might want to use hid-multitouch for it, with the
> Scan Time forwarded by the device, but what do you have in mind?
that'd be my question as well. I'm all for more precise evdev timestamps but
there's some overlap with MSC_TIMESTAMP (which at least libinput isn't
handling well right now, with the exception of some quirk detection).
but yeah, overall this is a good solution from my POV.
Cheers,
Peter
> > > ---
> > > drivers/input/evdev.c | 42 --
> > > drivers/input/input.c | 17 +
> > > include/linux/input.h | 38 ++
> > > 3 files changed, 71 insertions(+), 26 deletions(-)
> > >
> > > diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
> > > index 867c2cfd0038..a331efa0a3f6 100644
> > > --- a/drivers/input/evdev.c
> > > +++ b/drivers/input/evdev.c
> > > @@ -25,13 +25,6 @@
> > > #include
> > > #include "input-compat.h"
> > >
> > > -enum evdev_clock_type {
> > > - EV_CLK_REAL = 0,
> > > - EV_CLK_MONO,
> > > - EV_CLK_BOOT,
> > > - EV_CLK_MAX
> > > -};
> > > -
> > > struct evdev {
> > > int open;
> > > struct input_handle handle;
> > > @@ -53,7 +46,7 @@ struct evdev_client {
> > > struct fasync_struct *fasync;
> > > struct evdev *evdev;
> > > struct list_head node;
> > > - unsigned int clk_type;
> > > + input_clk_t clk_type;
> > > bool revoked;
> > > unsigned long *evmasks[EV_CNT];
> > > unsigned int bufsize;
> > > @@ -150,16 +143,18 @@ 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;
> > > + ktime_t *time = input_get_timestamp(client->evdev->handle.dev);
> > >
> > > - 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 INPUT_CLK_REAL:
> > > + case INPUT_CLK_MONO:
> > > + ts = ktime_to_timespec64(time[client->clk_type]);
> > > + break;
> > > + default:
> > > + ts = ktime_to_timespec64(time[INPUT_CLK_BOOT]);
> >
> > Add "break" here please.
> >
> > > + }
> > >
> > > - ts = ktime_to_timespec64(time);
> > > ev.input_event_sec = ts.tv_sec;
> > > ev.input_event_usec = ts.tv_nsec / NSEC_PER_USEC;
> > > ev.type = EV_SYN;
> > > @@ -185,21 +180,21 @@ static void evdev_queue_syn_dropped(struct
> > > evdev_client *client)
> > > spin_unlock_irqrestore(&client->buffer_lock, flags);
> > > }
> > >
> > > -static int evdev_set_clk_type(struct evdev_client *client, unsigned int
> > > clkid)
> > > +static int evdev_set_clk_type(struct evdev_client *client, clockid_t
> > > clkid)
> > > {
> > > unsigned long flags;
> > > - unsigned int clk_type;
> > > + input_clk_t clk_type;
> > >
> > > switch (clkid) {
> > >
> > > case CLOCK_REALTIME:
> > > - clk_type = EV_CLK_REAL;
> > > + clk_type = INPUT_CLK_REAL;
> > > break;
> > > case CLOCK_MONOTONIC:
> > > - clk_type = EV_CLK_MONO;
> > > + clk_type = INPUT_CLK_MONO;
> > > break;
> > > case CLOCK_BOOTTIME:
> > > - clk_type = EV_CLK_BOOT;
> > > + clk_type = INPUT_CLK_BOOT;
> > > break;
> > > default:
> > > return -EINVAL;
> > > @@ -307,12 +302,7 @@ static void evdev_events(struct input_handle *handle,
> > > {
> > > struct evdev *evdev = handle->private;
> > > struct evdev_client *client;
> > > - ktime_t 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_an
Re: [PATCH v2 08/10] Input: elan_i2c - export true width/height
On Wed, May 29, 2019 at 09:16:38AM +0200, Benjamin Tissoires wrote: > On Wed, May 29, 2019 at 2:12 AM Sean O'Brien wrote: > > > > We do still use a maxed out major axis as a signal for a palm in the > > touchscreen > > logic, but I'm not too concerned because if that axis is maxed out, the > > contact > > should probably be treated as a palm anyway... > > > > I'm more concerned with this affecting our gesture detection for > > touchpad. It looks > > like this change would cause all contacts to reported as some percentage > > bigger > > than they are currently. Can you give me an idea of how big that percentage > > is? > > On the P52, I currently have: > [ +0.09] max:(3045,1731) drivers/input/mouse/elan_i2c_core.c:428 > [ +0.03] traces: (24,14) drivers/input/mouse/elan_i2c_core.c:429 > > -> with the computation done in the kernel: > width_ratio: 126 > height_ratio: 123 > > For my average finger, the reported traces are between 4 and 6: > With the ETP_FWIDTH_REDUCE: > Major between 144 to 216 > Minor between 132 to 198 > > Without: > Major between 504 to 756 > Minor between 492 to 738 > > So a rough augmentation of 350% > > For the Synaptics devices (over SMBus), they send the raw value of the > traces, so you will get a major/minor between 2 to 5. Max on these > axes is 15, so we should get the same percentage of value comparing to > the range. > Which is why libinput has a database of which device reports which > pressure/major/minor ranges as otherwise the values are just > impossible to understand. yeah, I've given up on trying to guess finger/thumb/palm sizes. git grep for these quirk names in libinput for the ranges: AttrTouchSizeRange AttrThumbSizeThreshold AttrPalmSizeThreshold There are also matching s/Size/Pressure/ entries for touchpads without major/minor. Looking at the database now, the palm size thresholds range entries are 5 (Wacom) and a set of 800-1600 for apple touchpads. So yeah, all this is really a bit random :) Feel free to steal those entries though and/or add to them where applicable. Cheers, Peter > > > > > On Tue, May 28, 2019 at 11:13 AM Harry Cutts wrote: > > > > > > On Mon, 27 May 2019 at 18:21, Dmitry Torokhov > > > wrote: > > > > > > > > Hi Benjamin, KT, > > > > > > > > On Mon, May 27, 2019 at 11:55:01AM +0800, 廖崇榮 wrote: > > > > > Hi > > > > > > > > > > -Original Message- > > > > > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] > > > > > Sent: Friday, May 24, 2019 5:37 PM > > > > > To: Dmitry Torokhov; KT Liao; Rob Herring; Aaron Ma; Hans de Goede > > > > > Cc: open list:HID CORE LAYER; lkml; devicet...@vger.kernel.org > > > > > Subject: Re: [PATCH v2 08/10] Input: elan_i2c - export true > > > > > width/height > > > > > > > > > > On Tue, May 21, 2019 at 3:28 PM Benjamin Tissoires > > > > > wrote: > > > > > > > > > > > > The width/height is actually in the same unit than X and Y. So we > > > > > > should not tamper the data, but just set the proper resolution, so > > > > > > that userspace can correctly detect which touch is a palm or a > > > > > > finger. > > > > > > > > > > > > Signed-off-by: Benjamin Tissoires > > > > > > > > > > > > -- > > > > > > > > > > > > new in v2 > > > > > > --- > > > > > > drivers/input/mouse/elan_i2c_core.c | 11 --- > > > > > > 1 file changed, 4 insertions(+), 7 deletions(-) > > > > > > > > > > > > diff --git a/drivers/input/mouse/elan_i2c_core.c > > > > > > b/drivers/input/mouse/elan_i2c_core.c > > > > > > index 7ff044c6cd11..6f4feedb7765 100644 > > > > > > --- a/drivers/input/mouse/elan_i2c_core.c > > > > > > +++ b/drivers/input/mouse/elan_i2c_core.c > > > > > > @@ -45,7 +45,6 @@ > > > > > > #define DRIVER_NAME"elan_i2c" > > > > > > #define ELAN_VENDOR_ID 0x04f3 > > > > > > #define ETP_MAX_PRESSURE 255 > > > > > > -#define ETP_FWIDTH_REDUCE 90 > > > > > > #define ETP_FINGER_WIDTH 15 > > > > > > #define ETP_RETRY_COUNT3 > > > > > > > > > > > > @@ -915,12 +914,8 @@ static void elan_report_contact(struct > > > > > > elan_tp_data *data, > > > > > > return; > > > > > > } > > > > > > > > > > > > - /* > > > > > > -* To avoid treating large finger as palm, let's > > > > > > reduce the > > > > > > -* width x and y per trace. > > > > > > -*/ > > > > > > - area_x = mk_x * (data->width_x - ETP_FWIDTH_REDUCE); > > > > > > - area_y = mk_y * (data->width_y - ETP_FWIDTH_REDUCE); > > > > > > + area_x = mk_x * data->width_x; > > > > > > + area_y = mk_y * data->width_y; > > > > > > > > > > > > major = max(area_x, area_y); > > > > > > minor = min(area_x, area_y); @@ -1123,8 +1118,10 @@ > > > > > > static int elan_setup_input_device(struct elan_tp_data *data) > > > > > > ETP_MAX_PRESSURE, 0, 0); > > > >
Re: 答复: 答复: 答复: [PATCH] input: alps-fix the issue the special alps trackpoint do not work.
On Fri, May 24, 2019 at 06:43:58PM +0800, Hui Wang wrote: > > On 2019/5/24 下午5:37, Peter Hutterer wrote: > > On Fri, May 24, 2019 at 03:37:57PM +0800, Hui Wang wrote: > > > On 2019/5/24 下午3:26, Pali Rohár wrote: > > > > On Friday 24 May 2019 13:50:53 Hui Wang wrote: > > > > > On 2019/5/24 下午1:36, Peter Hutterer wrote: > > > > > > On Fri, May 24, 2019 at 01:25:52PM +0800, Hui Wang wrote: > > > > > > > On 2019/5/23 下午2:01, Peter Hutterer wrote: > > > > > > > > On Wed, May 22, 2019 at 09:40:30AM +0200, Pali Rohár wrote: > > > > > > > > > On Wednesday 22 May 2019 07:30:43 Xiaoxiao Liu wrote: > > > > > > > > > > Hi Pali, > > > > > > > > > > > > > > > > > > > > Ok, and cannot you set ALPS_DUALPOINT flag based on that > > > > > > > > > > alps_check_is_trackpoint() result and then update > > > > > > > > > > alps_process_packet_ss4_v3() code to supports also > > > > > > > > > > V8 trackpoint packets? > > > > > > > > > > --> Yes, we can do like so, when we use the v8 method to > > > > > > > > > > process the trackpoint , the mouse speed is not ideal. > > > > > > > > > > Then we choose the standard mouse driver. > > > > > > > > > Mouse speed is something which is configurable. Have you > > > > > > > > > configured it > > > > > > > > > somehow? Also there is libinput project should handle these > > > > > > > > > settings > > > > > > > > > more properly. > > > > > > > > > > > > > > > > > > Adding Peter Hutterer, maintainer of libinput to loop. I > > > > > > > > > think he could > > > > > > > > > help with this problem. > > > > > > > > libinput has a quirk for a magic multiplier on trackpoints. it > > > > > > > > was the only > > > > > > > > solution I found that came close to "working" given that every > > > > > > > > device seems > > > > > > > > to provide some other random magic data. Doc for it is here: > > > > > > > > https://wayland.freedesktop.org/libinput/doc/latest/trackpoint-configuration.html > > > > > > > Hello Peter Hutterer, > > > > > > > > > > > > > > To adjust the trackpoint speed from userspace: > > > > > > > > > > > > > > If the libinput version is lower than 1.9.0, we could set > > > > > > > POINTINGSTICK_CONST_ACCEL=0.25 > > > > > > > > > > > > > > If the libinput version is higher than 1.12.0, we could set > > > > > > > AttrTrackpointMultiplier=0.25 > > > > > > > > > > > > > > But if we use libinput-1.10.0, how could we adjust the speed? > > > > > > The LIBINPUT_ATTR_TRACKPOINT_RANGE property, which didn't end up > > > > > > working > > > > > > well (hence why it got replaced again). See the docs here though: > > > > > > https://wayland.freedesktop.org/libinput/doc/1.10.0/trackpoints.html > > > > > > > > > > > > Cheers, > > > > > > Peter > > > > > OK, got it, Thanks. > > > > Is not here some database where for input device name / id is specified > > > > that property? So users do not have to invent what is correct value for > > > > their hardware? > > > Since the libinput version in the ubuntu 18.04 is 1.10, I tried to set > > > LIBINPUT_ATTR_TRACKPOINT_RANGE with different values (from 25, 20, 10, 5) > > > in > > > the udev hwdb database, I checked it with "udevadm info /dev/input/eventX" > > > to confirm the value is set to LIBINPUT_ATTR_TRACKPOINT_RANGE > > > successfully, > > > but looks like the cursor speed doesn't change at all. So for ubuntu > > > 18.04, > > > looks like we have to adjust the speed in the kernel driver. > > I don't think it's a good idea to make the kernel driver behaviour based on > > an EOL libinput version just because one version of ubuntu ships with that. > > 18.10 and 19.04 both ship with libinput 1.12. > > > > It'd be better to make sure it works well with a *current* version and then > > patch libinput on 18.04 where needed. > > OK, that is sth we need to do. But anyway it is a bit risky to backport > that much code and the whole folder of quirks to libinput 1.10.4, we need > to do lots of test to make sure there is no regression on other machines. > > Probably we only need to keep the quirks/30-vendor-alps.quirks to 1.10.4 and > drop other quirks, that will be better for our testing effort. might be worth looking at what is in 1.10.7, e.g. a3b3e85c0e looks like it may be of interest. That one suggests the range on some ALPS devices is over 100, so testing with 5-25 may really not have had any effect. Cheers, Peter
Re: 答复: 答复: 答复: [PATCH] input: alps-fix the issue the special alps trackpoint do not work.
On Fri, May 24, 2019 at 03:37:57PM +0800, Hui Wang wrote: > > On 2019/5/24 下午3:26, Pali Rohár wrote: > > On Friday 24 May 2019 13:50:53 Hui Wang wrote: > > > On 2019/5/24 下午1:36, Peter Hutterer wrote: > > > > On Fri, May 24, 2019 at 01:25:52PM +0800, Hui Wang wrote: > > > > > On 2019/5/23 下午2:01, Peter Hutterer wrote: > > > > > > On Wed, May 22, 2019 at 09:40:30AM +0200, Pali Rohár wrote: > > > > > > > On Wednesday 22 May 2019 07:30:43 Xiaoxiao Liu wrote: > > > > > > > > Hi Pali, > > > > > > > > > > > > > > > > Ok, and cannot you set ALPS_DUALPOINT flag based on that > > > > > > > > alps_check_is_trackpoint() result and then update > > > > > > > > alps_process_packet_ss4_v3() code to supports also > > > > > > > > V8 trackpoint packets? > > > > > > > > --> Yes, we can do like so, when we use the v8 method to > > > > > > > > process the trackpoint , the mouse speed is not ideal. > > > > > > > > Then we choose the standard mouse driver. > > > > > > > Mouse speed is something which is configurable. Have you > > > > > > > configured it > > > > > > > somehow? Also there is libinput project should handle these > > > > > > > settings > > > > > > > more properly. > > > > > > > > > > > > > > Adding Peter Hutterer, maintainer of libinput to loop. I think he > > > > > > > could > > > > > > > help with this problem. > > > > > > libinput has a quirk for a magic multiplier on trackpoints. it was > > > > > > the only > > > > > > solution I found that came close to "working" given that every > > > > > > device seems > > > > > > to provide some other random magic data. Doc for it is here: > > > > > > https://wayland.freedesktop.org/libinput/doc/latest/trackpoint-configuration.html > > > > > Hello Peter Hutterer, > > > > > > > > > > To adjust the trackpoint speed from userspace: > > > > > > > > > > If the libinput version is lower than 1.9.0, we could set > > > > > POINTINGSTICK_CONST_ACCEL=0.25 > > > > > > > > > > If the libinput version is higher than 1.12.0, we could set > > > > > AttrTrackpointMultiplier=0.25 > > > > > > > > > > But if we use libinput-1.10.0, how could we adjust the speed? > > > > The LIBINPUT_ATTR_TRACKPOINT_RANGE property, which didn't end up working > > > > well (hence why it got replaced again). See the docs here though: > > > > https://wayland.freedesktop.org/libinput/doc/1.10.0/trackpoints.html > > > > > > > > Cheers, > > > > Peter > > > OK, got it, Thanks. > > Is not here some database where for input device name / id is specified > > that property? So users do not have to invent what is correct value for > > their hardware? > > Since the libinput version in the ubuntu 18.04 is 1.10, I tried to set > LIBINPUT_ATTR_TRACKPOINT_RANGE with different values (from 25, 20, 10, 5) in > the udev hwdb database, I checked it with "udevadm info /dev/input/eventX" > to confirm the value is set to LIBINPUT_ATTR_TRACKPOINT_RANGE successfully, > but looks like the cursor speed doesn't change at all. So for ubuntu 18.04, > looks like we have to adjust the speed in the kernel driver. I don't think it's a good idea to make the kernel driver behaviour based on an EOL libinput version just because one version of ubuntu ships with that. 18.10 and 19.04 both ship with libinput 1.12. It'd be better to make sure it works well with a *current* version and then patch libinput on 18.04 where needed. Cheers, Peter
Re: 答复: 答复: 答复: [PATCH] input: alps-fix the issue the special alps trackpoint do not work.
On Fri, May 24, 2019 at 09:26:48AM +0200, Pali Rohár wrote: > On Friday 24 May 2019 13:50:53 Hui Wang wrote: > > On 2019/5/24 下午1:36, Peter Hutterer wrote: > > > On Fri, May 24, 2019 at 01:25:52PM +0800, Hui Wang wrote: > > > > On 2019/5/23 下午2:01, Peter Hutterer wrote: > > > > > On Wed, May 22, 2019 at 09:40:30AM +0200, Pali Rohár wrote: > > > > > > On Wednesday 22 May 2019 07:30:43 Xiaoxiao Liu wrote: > > > > > > > Hi Pali, > > > > > > > > > > > > > > Ok, and cannot you set ALPS_DUALPOINT flag based on that > > > > > > > alps_check_is_trackpoint() result and then update > > > > > > > alps_process_packet_ss4_v3() code to supports also > > > > > > > V8 trackpoint packets? > > > > > > > --> Yes, we can do like so, when we use the v8 method to process > > > > > > > the trackpoint , the mouse speed is not ideal. > > > > > > > Then we choose the standard mouse driver. > > > > > > Mouse speed is something which is configurable. Have you configured > > > > > > it > > > > > > somehow? Also there is libinput project should handle these settings > > > > > > more properly. > > > > > > > > > > > > Adding Peter Hutterer, maintainer of libinput to loop. I think he > > > > > > could > > > > > > help with this problem. > > > > > libinput has a quirk for a magic multiplier on trackpoints. it was > > > > > the only > > > > > solution I found that came close to "working" given that every device > > > > > seems > > > > > to provide some other random magic data. Doc for it is here: > > > > > https://wayland.freedesktop.org/libinput/doc/latest/trackpoint-configuration.html > > > > Hello Peter Hutterer, > > > > > > > > To adjust the trackpoint speed from userspace: > > > > > > > > If the libinput version is lower than 1.9.0, we could set > > > > POINTINGSTICK_CONST_ACCEL=0.25 > > > > > > > > If the libinput version is higher than 1.12.0, we could set > > > > AttrTrackpointMultiplier=0.25 > > > > > > > > But if we use libinput-1.10.0, how could we adjust the speed? > > > The LIBINPUT_ATTR_TRACKPOINT_RANGE property, which didn't end up working > > > well (hence why it got replaced again). See the docs here though: > > > https://wayland.freedesktop.org/libinput/doc/1.10.0/trackpoints.html > > > > > > Cheers, > > > Peter > > > > OK, got it, Thanks. > > Is not here some database where for input device name / id is specified > that property? So users do not have to invent what is correct value for > their hardware? yeah, libinput ships with a quirks database that sets those, but it relies on users to submit the quirks. https://gitlab.freedesktop.org/libinput/libinput/tree/master/quirks There's no "correct" value anyway, if you ask 3 users what the trackpoint should do you'll get 5 answers :) Cheers, Peter
Re: 答复: 答复: 答复: [PATCH] input: alps-fix the issue the special alps trackpoint do not work.
On Fri, May 24, 2019 at 01:25:52PM +0800, Hui Wang wrote: > > On 2019/5/23 下午2:01, Peter Hutterer wrote: > > On Wed, May 22, 2019 at 09:40:30AM +0200, Pali Rohár wrote: > > > On Wednesday 22 May 2019 07:30:43 Xiaoxiao Liu wrote: > > > > Hi Pali, > > > > > > > > Ok, and cannot you set ALPS_DUALPOINT flag based on that > > > > alps_check_is_trackpoint() result and then update > > > > alps_process_packet_ss4_v3() code to supports also > > > > V8 trackpoint packets? > > > > --> Yes, we can do like so, when we use the v8 method to process the > > > > trackpoint , the mouse speed is not ideal. > > > >Then we choose the standard mouse driver. > > > Mouse speed is something which is configurable. Have you configured it > > > somehow? Also there is libinput project should handle these settings > > > more properly. > > > > > > Adding Peter Hutterer, maintainer of libinput to loop. I think he could > > > help with this problem. > > libinput has a quirk for a magic multiplier on trackpoints. it was the only > > solution I found that came close to "working" given that every device seems > > to provide some other random magic data. Doc for it is here: > > https://wayland.freedesktop.org/libinput/doc/latest/trackpoint-configuration.html > > Hello Peter Hutterer, > > To adjust the trackpoint speed from userspace: > > If the libinput version is lower than 1.9.0, we could set > POINTINGSTICK_CONST_ACCEL=0.25 > > If the libinput version is higher than 1.12.0, we could set > AttrTrackpointMultiplier=0.25 > > But if we use libinput-1.10.0, how could we adjust the speed? The LIBINPUT_ATTR_TRACKPOINT_RANGE property, which didn't end up working well (hence why it got replaced again). See the docs here though: https://wayland.freedesktop.org/libinput/doc/1.10.0/trackpoints.html Cheers, Peter > > > > There are also different speeds depending on which xorg driver you'd use (or > > libinput/Wayland), so a "mouse speed is not ideal" is almost a guarantee, > > given a large enough variety of setups :) That's why we have the speed > > toggle, but I'm happy to hear any suggestions on how to make the trackpoint > > more useful (in libinput anyway). > > > > > I do not think it is a good idea to force back to generic PS/2 mouse > > > driver for touchpads and trackpoints. Native drivers for touchpads and > > > trackpoints supports multitouch, absolute reporting and lot of other > > > things... Also calculation of mouse speed from absolute positions on > > > touchpads can be more easily fixed as from emulated relative movements. > > Yeah, agree. Using PS/2 mouse drivers means you lose *all* the extra > > features touchpads have like palm detection, tapping, scrolling, gestures, > > etc. > > > > Cheers, > > Peter > > > > > Dmitry, what is your opinion about this problem? What should psmouse.ko > > > do in this situation? Disallow usage of absolute mode and force bare > > > PS/2 relative mode? > >
Re: 答复: 答复: 答复: [PATCH] input: alps-fix the issue the special alps trackpoint do not work.
On Wed, May 22, 2019 at 09:40:30AM +0200, Pali Rohár wrote: > On Wednesday 22 May 2019 07:30:43 Xiaoxiao Liu wrote: > > Hi Pali, > > > > Ok, and cannot you set ALPS_DUALPOINT flag based on that > > alps_check_is_trackpoint() result and then update > > alps_process_packet_ss4_v3() code to supports also > > V8 trackpoint packets? > > --> Yes, we can do like so, when we use the v8 method to process the > > trackpoint , the mouse speed is not ideal. > > Then we choose the standard mouse driver. > > Mouse speed is something which is configurable. Have you configured it > somehow? Also there is libinput project should handle these settings > more properly. > > Adding Peter Hutterer, maintainer of libinput to loop. I think he could > help with this problem. libinput has a quirk for a magic multiplier on trackpoints. it was the only solution I found that came close to "working" given that every device seems to provide some other random magic data. Doc for it is here: https://wayland.freedesktop.org/libinput/doc/latest/trackpoint-configuration.html There are also different speeds depending on which xorg driver you'd use (or libinput/Wayland), so a "mouse speed is not ideal" is almost a guarantee, given a large enough variety of setups :) That's why we have the speed toggle, but I'm happy to hear any suggestions on how to make the trackpoint more useful (in libinput anyway). > I do not think it is a good idea to force back to generic PS/2 mouse > driver for touchpads and trackpoints. Native drivers for touchpads and > trackpoints supports multitouch, absolute reporting and lot of other > things... Also calculation of mouse speed from absolute positions on > touchpads can be more easily fixed as from emulated relative movements. Yeah, agree. Using PS/2 mouse drivers means you lose *all* the extra features touchpads have like palm detection, tapping, scrolling, gestures, etc. Cheers, Peter > > Dmitry, what is your opinion about this problem? What should psmouse.ko > do in this situation? Disallow usage of absolute mode and force bare > PS/2 relative mode?
Re: [PATCH] HID: fix A4Tech horizontal scrolling
On Fri, May 03, 2019 at 01:59:23PM +0200, Benjamin Tissoires wrote: > Hi, > > On Fri, May 3, 2019 at 11:43 AM Igor Kushnir wrote: > > > > Hi Benjamin, > > > > On 5/3/19 10:36 AM, Benjamin Tissoires wrote: > > > Hi, > > > > > > On Thu, May 2, 2019 at 11:37 PM Błażej Szczygieł wrote: > > >> > > >> Since recent high resolution scrolling changes the A4Tech driver must > > >> check for the "REL_WHEEL_HI_RES" usage code. > > >> > > >> Fixes: 2dc702c991e3774af9d7ce410eef410ca9e2357e (HID: input: use the > > >> Resolution Multiplier for high-resolution scrolling) > > >> > > >> Signed-off-by: Błażej Szczygieł > > > > > > Thanks for the patch. I do not doubt this fixes the issues, but I > > > still wonder if we should not export REL_HWHEEL_HI_RES instead of > > > REL_HWHEEL events. > > > > > > If you mean exporting REL_HWHEEL_HI_RES instead of REL_HWHEEL from > > hid-a4tech.c, then it makes sense to me, though I do not know the code > > well enough to be certain. > > Yep, that's what I meant. I am worried that userspace doesn't know > well how to deal with a device that mixes the new and old REL_WHEEL > events. sorry, I'm not sure what you mean here. The new events are always mixed with the old ones anyway, and both should be treated as separate event streams. The kernel interface to userspace is fairly easy to deal with, it's the rest that's a bit of mess. [..] > > > > OK, thanks both of you for your logs, this is helpful. > So just in case I need to come back later, the horizontal wheel is > "just" the normal wheel plus a modifier in the report. > > Anyway, ideally, can we have a v2 of the patch with the 2 changes > requested above in the commit message and the introduction of > REL_HWHEEL_HI_RES events in addition to REL_HWHEEL? > REL_HWHEEL_HI_RES should report `120*value` and we should also keep > the reporting of REL_WHEEL as it is currently. > > Peter, I grepped in the hid code, and it seems hid-cypress.c is having > the exact same issue. Sigh. yeah, I found that too when grepping through it. seems to be the only other one though and we can use Błażej's patch as boilerplate once it's done. Cheers, Peter
Re: [PATCH v2] HID: fix A4Tech horizontal scrolling
On Fri, May 03, 2019 at 10:28:36PM +0200, Błażej Szczygieł wrote:
> Since recent high resolution scrolling changes the A4Tech driver must
> check for the "REL_WHEEL_HI_RES" usage code.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=203369
> Fixes: 2dc702c991e3774af9d7ce410eef410ca9e2357e ("HID: input: use the
> Resolution Multiplier for high-resolution scrolling")
>
> Signed-off-by: Błażej Szczygieł
> ---
> Changes in v2:
> - changed commit message
>
> drivers/hid/hid-a4tech.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hid/hid-a4tech.c b/drivers/hid/hid-a4tech.c
> index 9428ea7cdf8a..fafb9fa558e7 100644
> --- a/drivers/hid/hid-a4tech.c
> +++ b/drivers/hid/hid-a4tech.c
> @@ -38,7 +38,7 @@ static int a4_input_mapped(struct hid_device *hdev, struct
> hid_input *hi,
> {
> struct a4tech_sc *a4 = hid_get_drvdata(hdev);
>
> - if (usage->type == EV_REL && usage->code == REL_WHEEL)
> + if (usage->type == EV_REL && usage->code == REL_WHEEL_HI_RES)
> set_bit(REL_HWHEEL, *bit);
>
> if ((a4->quirks & A4_2WHEEL_MOUSE_HACK_7) && usage->hid == 0x00090007)
> @@ -60,7 +60,7 @@ static int a4_event(struct hid_device *hdev, struct
> hid_field *field,
> input = field->hidinput->input;
>
> if (a4->quirks & A4_2WHEEL_MOUSE_HACK_B8) {
> - if (usage->type == EV_REL && usage->code == REL_WHEEL) {
> + if (usage->type == EV_REL && usage->code == REL_WHEEL_HI_RES) {
> a4->delayed_value = value;
> return 1;
> }
> @@ -77,7 +77,7 @@ static int a4_event(struct hid_device *hdev, struct
> hid_field *field,
> return 1;
> }
>
> - if (usage->code == REL_WHEEL && a4->hw_wheel) {
> + if (usage->code == REL_WHEEL_HI_RES && a4->hw_wheel) {
> input_event(input, usage->type, REL_HWHEEL, value);
You'll need to send both events here, so please add:
input_event(input, usage->type, REL_HWHEEL_HI_RES, value * 120);
assume that wheel and wheel_hi_res are two separate event streams for the
same axis, userspace may listen to either or both. if you only send the
legacy event, newer userspace won't receive any scroll events as it may only
look for the new hi-res events.
Check with evtest/evemu/libinput record after, you should see multiples of
120 on the hi-res axis for every legacy wheel event.
Cheers,
Peter
> return 1;
> }
> --
> 2.21.0
>
[PATCH] HID: logitech: Handle 0 scroll events for the m560
hidpp_scroll_counter_handle_scroll() doesn't expect a 0-value scroll event, it gets interpreted as a negative scroll direction event. This can cause scroll direction resets and thus broken scrolling. Reported-and-tested-by: Aimo Metsälä Signed-off-by: Peter Hutterer --- drivers/hid/hid-logitech-hidpp.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c index 15ed6177a7a3..f040c8a7f9a9 100644 --- a/drivers/hid/hid-logitech-hidpp.c +++ b/drivers/hid/hid-logitech-hidpp.c @@ -2608,8 +2608,9 @@ static int m560_raw_event(struct hid_device *hdev, u8 *data, int size) input_report_rel(mydata->input, REL_Y, v); v = hid_snto32(data[6], 8); - hidpp_scroll_counter_handle_scroll( - &hidpp->vertical_wheel_counter, v); + if (v != 0) + hidpp_scroll_counter_handle_scroll( + &hidpp->vertical_wheel_counter, v); input_sync(mydata->input); } -- 2.20.1
Re: [PATCH] Input: uinput - fix undefined behavior in uinput_validate_absinfo()
On Mon, Jan 14, 2019 at 02:07:56PM -0800, Dmitry Torokhov wrote:
> On Mon, Jan 14, 2019 at 02:04:48PM -0800, Dmitry Torokhov wrote:
> > An integer overflow may arise in uinput_validate_absinfo() if "max - min"
> > can't be represented by an "int". We should check for overflow before
> > trying to use the result.
> >
> > Reported-by: Kyungtae Kim
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Dmitry Torokhov
> > ---
> > drivers/input/misc/uinput.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
> > index 8ec483e8688b..26ec603fe220 100644
> > --- a/drivers/input/misc/uinput.c
> > +++ b/drivers/input/misc/uinput.c
> > @@ -39,6 +39,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include "../input-compat.h"
> >
> > @@ -405,7 +406,7 @@ static int uinput_open(struct inode *inode, struct file
> > *file)
> > static int uinput_validate_absinfo(struct input_dev *dev, unsigned int
> > code,
> >const struct input_absinfo *abs)
> > {
> > - int min, max;
> > + int min, max, range;
> >
> > min = abs->minimum;
> > max = abs->maximum;
> > @@ -417,7 +418,7 @@ static int uinput_validate_absinfo(struct input_dev
> > *dev, unsigned int code,
> > return -EINVAL;
> > }
> >
> > - if (abs->flat > max - min) {
> > + if (check_sub_overflow(max, min, &range) && abs->flat > range) {
>
> This should be !check_sub_overflow(...) of course.
Reviewed-by: Peter Hutterer with that in place,
thanks.
Cheers,
Peter
> > printk(KERN_DEBUG
> >"%s: abs_flat #%02x out of range: %d (min:%d/max:%d)\n",
> >UINPUT_NAME, code, abs->flat, min, max);
> > --
> > 2.20.1.97.g81188d93c3-goog
> >
> >
> > --
> > Dmitry
>
> --
> Dmitry
Re: [PATCH] Input: elantech - Disable elan-i2c for P52 and P72
On Wed, Dec 12, 2018 at 04:42:05PM +0100, Benjamin Tissoires wrote:
> The current implementation of elan_i2c is known to not support those
> 2 laptops.
>
> A proper fix is to tweak both elantech and elan_i2c to transmit the
> correct information from PS/2, which would make a bad candidate for
> stable.
>
> So to give us some time for fixing the root of the problem, disable
> elan_i2c for the devices we know are not behaving properly.
>
> Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600
> Link: https://bugs.archlinux.org/task/59714
> Fixes: df077237cf55 Input: elantech - detect new ICs and setup Host Notify
> for them
>
> Cc: sta...@vger.kernel.org # v4.18+
> Signed-off-by: Benjamin Tissoires
Acked-by: Peter Hutterer
Cheers,
Peter
> ---
> drivers/input/mouse/elantech.c | 18 --
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
> index 2d95e8d93cc7..830ae9f07045 100644
> --- a/drivers/input/mouse/elantech.c
> +++ b/drivers/input/mouse/elantech.c
> @@ -1767,6 +1767,18 @@ static int elantech_smbus =
> IS_ENABLED(CONFIG_MOUSE_ELAN_I2C_SMBUS) ?
> module_param_named(elantech_smbus, elantech_smbus, int, 0644);
> MODULE_PARM_DESC(elantech_smbus, "Use a secondary bus for the Elantech
> device.");
>
> +static const char * const i2c_blacklist_pnp_ids[] = {
> + /*
> + * these are known to not be working properly as bits are missing
> + * in elan_i2c
> + */
> + "LEN2131", /* ThinkPad P52 w/ NFC */
> + "LEN2132", /* ThinkPad P52 */
> + "LEN2133", /* ThinkPad P72 w/ NFC */
> + "LEN2134", /* ThinkPad P72 */
> + NULL
> +};
> +
> static int elantech_create_smbus(struct psmouse *psmouse,
>struct elantech_device_info *info,
>bool leave_breadcrumbs)
> @@ -1802,10 +1814,12 @@ static int elantech_setup_smbus(struct psmouse
> *psmouse,
>
> if (elantech_smbus == ELANTECH_SMBUS_NOT_SET) {
> /*
> - * New ICs are enabled by default.
> + * New ICs are enabled by default, unless mentioned in
> + * i2c_blacklist_pnp_ids.
>* Old ICs are up to the user to decide.
>*/
> - if (!ETP_NEW_IC_SMBUS_HOST_NOTIFY(info->fw_version))
> + if (!ETP_NEW_IC_SMBUS_HOST_NOTIFY(info->fw_version) ||
> + psmouse_matches_pnp_id(psmouse, i2c_blacklist_pnp_ids))
> return -ENXIO;
> }
>
> --
> 2.19.2
>
[PATCH] Documentation: hid: fix wrong data structure reference for UHID_OUTPUT
Signed-off-by: Peter Hutterer --- Documentation/hid/uhid.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/hid/uhid.txt b/Documentation/hid/uhid.txt index c8656dd029a9..958fff945304 100644 --- a/Documentation/hid/uhid.txt +++ b/Documentation/hid/uhid.txt @@ -160,7 +160,7 @@ them but you should handle them according to your needs. UHID_OUTPUT: This is sent if the HID device driver wants to send raw data to the I/O device on the interrupt channel. You should read the payload and forward it to - the device. The payload is of type "struct uhid_data_req". + the device. The payload is of type "struct uhid_output_req". This may be received even though you haven't received UHID_OPEN, yet. UHID_GET_REPORT: -- 2.19.2
Re: [PATCH] Input: restore EV_ABS ABS_RESERVED
On Thu, Dec 06, 2018 at 10:24:11AM +0100, Benjamin Tissoires wrote: > On Thu, Dec 6, 2018 at 9:36 AM Martin Kepplinger > wrote: > > > > On 06.12.18 00:03, Peter Hutterer wrote: > > > ABS_RESERVED was added in d9ca1c990a7 and accidentally removed as part of > > > ffe0e7cf290f5c9 when the high-resolution scrolling code was removed. > > > > > > Signed-off-by: Peter Hutterer > > > > Reviewed-by: Martin Kepplinger > > Acked-by: Benjamin Tissoires > > Dmitry, I do not think this one will conflict with the high res wheel > patches, so I think it should be safe to take it through your tree. > If you think it'll be an issue, I can also take it through the HID one. fwiw, patch was made on top of v4.20-rc5, so it shouldn't conflict. Cheers, Peter
[PATCH] Input: restore EV_ABS ABS_RESERVED
ABS_RESERVED was added in d9ca1c990a7 and accidentally removed as part of ffe0e7cf290f5c9 when the high-resolution scrolling code was removed. Signed-off-by: Peter Hutterer --- include/uapi/linux/input-event-codes.h | 9 + 1 file changed, 9 insertions(+) diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h index 3eb5a4c3d60a..ae366b87426a 100644 --- a/include/uapi/linux/input-event-codes.h +++ b/include/uapi/linux/input-event-codes.h @@ -752,6 +752,15 @@ #define ABS_MISC 0x28 +/* + * 0x2e is reserved and should not be used in input drivers. + * It was used by HID as ABS_MISC+6 and userspace needs to detect if + * the next ABS_* event is correct or is just ABS_MISC + n. + * We define here ABS_RESERVED so userspace can rely on it and detect + * the situation described above. + */ +#define ABS_RESERVED 0x2e + #define ABS_MT_SLOT0x2f/* MT slot being modified */ #define ABS_MT_TOUCH_MAJOR 0x30/* Major axis of touching ellipse */ #define ABS_MT_TOUCH_MINOR 0x31/* Minor axis (omit if circular) */ -- 2.19.2
[PATCH v3 7/8] HID: logitech: Enable high-resolution scrolling on Logitech mice
From: Harry Cutts
There are three features used by various Logitech mice for
high-resolution scrolling: the scrolling acceleration bit in HID++ 1.0,
and the x2120 and x2121 features in HID++ 2.0 and above. This patch
supports all three, and uses the multiplier reported by the mouse for
the HID++ 2.0+ features.
The full list of product IDs of mice which support high-resolution
scrolling was provided by Logitech, but the patch was tested using the
following mice (using the Unifying receiver):
* HID++ 1.0: Anywhere MX, Performance MX
* x2120: M560
* x2121: MX Anywhere 2, MX Master 2S
This patch is a combinations of the now-reverted commits 1ff2e1a44e0,
d56ca9855bf9, 5fe2ccbef9d, 044ee89028 together with some extra bits for the
directional and timeout-based reset.
The previous patch series was in hid-input, it appears this remainder
handling is logitech-specific and was moved to hid-logitech-hidpp.c and
renamed accordingly.
Signed-off-by: Harry Cutts
Signed-off-by: Peter Hutterer
---
Changes to v1:
- get rid of the timer in favour of sched_clock()
- drop storing the multiplier and calculate value on the fly
Changes to v2:
- m560 now has REL_HWHEEL_HI_RES (untested, I don't have the device)
drivers/hid/hid-logitech-hidpp.c | 301 ++-
1 file changed, 295 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 95ba9db6e613..a66daf8acd87 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -64,6 +65,14 @@ MODULE_PARM_DESC(disable_tap_to_click,
#define HIDPP_QUIRK_NO_HIDINPUTBIT(23)
#define HIDPP_QUIRK_FORCE_OUTPUT_REPORTS BIT(24)
#define HIDPP_QUIRK_UNIFYING BIT(25)
+#define HIDPP_QUIRK_HI_RES_SCROLL_1P0 BIT(26)
+#define HIDPP_QUIRK_HI_RES_SCROLL_X2120BIT(27)
+#define HIDPP_QUIRK_HI_RES_SCROLL_X2121BIT(28)
+
+/* Convenience constant to check for any high-res support. */
+#define HIDPP_QUIRK_HI_RES_SCROLL (HIDPP_QUIRK_HI_RES_SCROLL_1P0 | \
+HIDPP_QUIRK_HI_RES_SCROLL_X2120 | \
+HIDPP_QUIRK_HI_RES_SCROLL_X2121)
#define HIDPP_QUIRK_DELAYED_INIT HIDPP_QUIRK_NO_HIDINPUT
@@ -128,6 +137,25 @@ struct hidpp_battery {
bool online;
};
+/**
+ * struct hidpp_scroll_counter - Utility class for processing high-resolution
+ * scroll events.
+ * @dev: the input device for which events should be reported.
+ * @wheel_multiplier: the scalar multiplier to be applied to each wheel event
+ * @remainder: counts the number of high-resolution units moved since the last
+ * low-resolution event (REL_WHEEL or REL_HWHEEL) was sent. Should
+ * only be used by class methods.
+ * @direction: direction of last movement (1 or -1)
+ * @last_time: last event time, used to reset remainder after inactivity
+ */
+struct hidpp_scroll_counter {
+ struct input_dev *dev;
+ int wheel_multiplier;
+ int remainder;
+ int direction;
+ unsigned long long last_time;
+};
+
struct hidpp_device {
struct hid_device *hid_dev;
struct mutex send_mutex;
@@ -149,6 +177,7 @@ struct hidpp_device {
unsigned long capabilities;
struct hidpp_battery battery;
+ struct hidpp_scroll_counter vertical_wheel_counter;
};
/* HID++ 1.0 error codes */
@@ -391,6 +420,67 @@ static void hidpp_prefix_name(char **name, int name_length)
*name = new_name;
}
+/**
+ * hidpp_scroll_counter_handle_scroll() - Send high- and low-resolution scroll
+ *events given a high-resolution wheel
+ *movement.
+ * @counter: a hid_scroll_counter struct describing the wheel.
+ * @hi_res_value: the movement of the wheel, in the mouse's high-resolution
+ *units.
+ *
+ * Given a high-resolution movement, this function converts the movement into
+ * fractions of 120 and emits high-resolution scroll events for the input
+ * device. It also uses the multiplier from &struct hid_scroll_counter to
+ * emit low-resolution scroll events when appropriate for
+ * backwards-compatibility with userspace input libraries.
+ */
+static void hidpp_scroll_counter_handle_scroll(struct hidpp_scroll_counter
*counter,
+ int hi_res_value)
+{
+ int low_res_value, remainder, direction;
+ unsigned long long now, previous;
+
+ hi_res_value = hi_res_value * 120/counter->wheel_multiplier;
+ input_report_rel(counter->dev, REL_WHEEL_HI_RES, hi_res_value);
+
+ remainder = counter->remainder;
+ direction = hi_res_value > 0 ? 1 : -1;
+
+ now = sched_clock();
+ pre
[PATCH v3 3/8] HID: core: process the Resolution Multiplier
The Resolution Multiplier is a feature report that modifies the value of
Usages within the same Logical Collection. If the multiplier is set to
anything but 1, the hardware reports (value * multiplier) for the same amount
of physical movement, i.e. the value we receive in the kernel is
pre-multiplied.
The hardware may either send a single (value * multiplier), or by sending
multiplier as many reports with the same value, or a combination of these two
options. For example, when the Microsoft Sculpt Ergonomic mouse Resolution
Multiplier is set to 12, the Wheel sends out 12 for every detent but AC Pan
sends out a value of 3 at 4 times the frequency.
The effective multiplier is based on the physical min/max of the multiplier
field, a logical min/max of [0,1] with a physical min/max of [1,8] means the
multiplier is either 1 or 8.
The Resolution Multiplier was introduced for high-resolution scrolling in
Windows Vista and is commonly used on Microsoft mice.
The recommendation for the Resolution Multiplier is to default to 1 for
backwards compatibility. This patch adds an arbitrary upper limit at 255. The
only known use case for the Resolution Multiplier is for scroll wheels where the
multiplier has to be a fraction of 120 to work with Windows.
Signed-off-by: Peter Hutterer
---
Changes since v1, v2:
- expanded the commit message with more detail
drivers/hid/hid-core.c | 170 +
include/linux/hid.h| 5 ++
2 files changed, 175 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 43d488a45120..f41d5fe51abe 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -294,6 +294,7 @@ static int hid_add_field(struct hid_parser *parser,
unsigned report_type, unsign
field->usage[i].collection_index =
parser->local.collection_index[j];
field->usage[i].usage_index = i;
+ field->usage[i].resolution_multiplier = 1;
}
field->maxusage = usages;
@@ -947,6 +948,167 @@ struct hid_report *hid_validate_values(struct hid_device
*hid,
}
EXPORT_SYMBOL_GPL(hid_validate_values);
+static int hid_calculate_multiplier(struct hid_device *hid,
+struct hid_field *multiplier)
+{
+ int m;
+ __s32 v = *multiplier->value;
+ __s32 lmin = multiplier->logical_minimum;
+ __s32 lmax = multiplier->logical_maximum;
+ __s32 pmin = multiplier->physical_minimum;
+ __s32 pmax = multiplier->physical_maximum;
+
+ /*
+* "Because OS implementations will generally divide the control's
+* reported count by the Effective Resolution Multiplier, designers
+* should take care not to establish a potential Effective
+* Resolution Multiplier of zero."
+* HID Usage Table, v1.12, Section 4.3.1, p31
+*/
+ if (lmax - lmin == 0)
+ return 1;
+ /*
+* Handling the unit exponent is left as an exercise to whoever
+* finds a device where that exponent is not 0.
+*/
+ m = ((v - lmin)/(lmax - lmin) * (pmax - pmin) + pmin);
+ if (unlikely(multiplier->unit_exponent != 0)) {
+ hid_warn(hid,
+"unsupported Resolution Multiplier unit exponent %d\n",
+multiplier->unit_exponent);
+ }
+
+ /* There are no devices with an effective multiplier > 255 */
+ if (unlikely(m == 0 || m > 255 || m < -255)) {
+ hid_warn(hid, "unsupported Resolution Multiplier %d\n", m);
+ m = 1;
+ }
+
+ return m;
+}
+
+static void hid_apply_multiplier_to_field(struct hid_device *hid,
+ struct hid_field *field,
+ struct hid_collection
*multiplier_collection,
+ int effective_multiplier)
+{
+ struct hid_collection *collection;
+ struct hid_usage *usage;
+ int i;
+
+ /*
+* If multiplier_collection is NULL, the multiplier applies
+* to all fields in the report.
+* Otherwise, it is the Logical Collection the multiplier applies to
+* but our field may be in a subcollection of that collection.
+*/
+ for (i = 0; i < field->maxusage; i++) {
+ usage = &field->usage[i];
+
+ collection = &hid->collection[usage->collection_index];
+ while (collection && collection != multiplier_collection)
+ collection = collection->parent;
+
+ if (collection || multiplier_collection == NULL)
+ usage->resolution_multiplier = effective_multiplier;
+
+ }
+}
+
+static void hid_apply_multiplier(struct hid_device *hid,
+struct hid_fie
[PATCH v3 8/8] HID: logitech: Use LDJ_DEVICE macro for existing Logitech mice
From: Harry Cutts
Signed-off-by: Harry Cutts
Reviewed-by: Benjamin Tissoires
Signed-off-by: Peter Hutterer
---
Changes to v1, v2:
- reordered from 6/8 to 8/8 so the intermediate steps all build
drivers/hid/hid-logitech-hidpp.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index a66daf8acd87..15ed6177a7a3 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -3362,13 +3362,11 @@ static void hidpp_remove(struct hid_device *hdev)
static const struct hid_device_id hidpp_devices[] = {
{ /* wireless touchpad */
- HID_DEVICE(BUS_USB, HID_GROUP_LOGITECH_DJ_DEVICE,
- USB_VENDOR_ID_LOGITECH, 0x4011),
+ LDJ_DEVICE(0x4011),
.driver_data = HIDPP_QUIRK_CLASS_WTP | HIDPP_QUIRK_DELAYED_INIT |
HIDPP_QUIRK_WTP_PHYSICAL_BUTTONS },
{ /* wireless touchpad T650 */
- HID_DEVICE(BUS_USB, HID_GROUP_LOGITECH_DJ_DEVICE,
- USB_VENDOR_ID_LOGITECH, 0x4101),
+ LDJ_DEVICE(0x4101),
.driver_data = HIDPP_QUIRK_CLASS_WTP | HIDPP_QUIRK_DELAYED_INIT },
{ /* wireless touchpad T651 */
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH,
@@ -3408,16 +3406,13 @@ static const struct hid_device_id hidpp_devices[] = {
{ /* Mouse Logitech Performance MX */
LDJ_DEVICE(0x101a), .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_1P0 },
{ /* Keyboard logitech K400 */
- HID_DEVICE(BUS_USB, HID_GROUP_LOGITECH_DJ_DEVICE,
- USB_VENDOR_ID_LOGITECH, 0x4024),
+ LDJ_DEVICE(0x4024),
.driver_data = HIDPP_QUIRK_CLASS_K400 },
{ /* Solar Keyboard Logitech K750 */
- HID_DEVICE(BUS_USB, HID_GROUP_LOGITECH_DJ_DEVICE,
- USB_VENDOR_ID_LOGITECH, 0x4002),
+ LDJ_DEVICE(0x4002),
.driver_data = HIDPP_QUIRK_CLASS_K750 },
- { HID_DEVICE(BUS_USB, HID_GROUP_LOGITECH_DJ_DEVICE,
- USB_VENDOR_ID_LOGITECH, HID_ANY_ID)},
+ { LDJ_DEVICE(HID_ANY_ID) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_G920_WHEEL),
.driver_data = HIDPP_QUIRK_CLASS_G920 |
HIDPP_QUIRK_FORCE_OUTPUT_REPORTS},
--
2.19.2
[PATCH v3 5/8] HID: logitech-hidpp: fix typo, hiddpp to hidpp
Signed-off-by: Peter Hutterer
---
Unchanged since v1
drivers/hid/hid-logitech-hidpp.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 19cc980eebce..22b37a3844d1 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -1465,7 +1465,7 @@ struct hidpp_ff_work_data {
u8 size;
};
-static const signed short hiddpp_ff_effects[] = {
+static const signed short hidpp_ff_effects[] = {
FF_CONSTANT,
FF_PERIODIC,
FF_SINE,
@@ -1480,7 +1480,7 @@ static const signed short hiddpp_ff_effects[] = {
-1
};
-static const signed short hiddpp_ff_effects_v2[] = {
+static const signed short hidpp_ff_effects_v2[] = {
FF_RAMP,
FF_FRICTION,
FF_INERTIA,
@@ -1873,11 +1873,11 @@ static int hidpp_ff_init(struct hidpp_device *hidpp, u8
feature_index)
version = bcdDevice & 255;
/* Set supported force feedback capabilities */
- for (j = 0; hiddpp_ff_effects[j] >= 0; j++)
- set_bit(hiddpp_ff_effects[j], dev->ffbit);
+ for (j = 0; hidpp_ff_effects[j] >= 0; j++)
+ set_bit(hidpp_ff_effects[j], dev->ffbit);
if (version > 1)
- for (j = 0; hiddpp_ff_effects_v2[j] >= 0; j++)
- set_bit(hiddpp_ff_effects_v2[j], dev->ffbit);
+ for (j = 0; hidpp_ff_effects_v2[j] >= 0; j++)
+ set_bit(hidpp_ff_effects_v2[j], dev->ffbit);
/* Read number of slots available in device */
error = hidpp_send_fap_command_sync(hidpp, feature_index,
--
2.19.2
[PATCH v3 2/8] HID: core: store the collections as a basic tree
For each collection parsed, store a pointer to the parent collection
(if any). This makes it a lot easier to look up which collection(s)
any given item is part of
Signed-off-by: Peter Hutterer
---
No changes since v1
drivers/hid/hid-core.c | 4
include/linux/hid.h| 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 5bec9244c45b..43d488a45120 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -172,6 +172,8 @@ static int open_collection(struct hid_parser *parser,
unsigned type)
collection->type = type;
collection->usage = usage;
collection->level = parser->collection_stack_ptr - 1;
+ collection->parent = parser->active_collection;
+ parser->active_collection = collection;
if (type == HID_COLLECTION_APPLICATION)
parser->device->maxapplication++;
@@ -190,6 +192,8 @@ static int close_collection(struct hid_parser *parser)
return -EINVAL;
}
parser->collection_stack_ptr--;
+ if (parser->active_collection)
+ parser->active_collection = parser->active_collection->parent;
return 0;
}
diff --git a/include/linux/hid.h b/include/linux/hid.h
index a355d61940f2..fdfda898656c 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -427,6 +427,7 @@ struct hid_local {
*/
struct hid_collection {
+ struct hid_collection *parent;
unsigned type;
unsigned usage;
unsigned level;
@@ -650,6 +651,7 @@ struct hid_parser {
unsigned int *collection_stack;
unsigned int collection_stack_ptr;
unsigned int collection_stack_size;
+ struct hid_collection *active_collection;
struct hid_device*device;
unsigned int scan_flags;
};
--
2.19.2
[PATCH v3 6/8] HID: logitech: Add function to enable HID++ 1.0 "scrolling acceleration"
From: Harry Cutts
"Scrolling acceleration" is a bit of a misnomer: it doesn't deal with
acceleration at all. However, that's the name used in Logitech's spec,
so I used it here.
Signed-off-by: Harry Cutts
Reviewed-by: Benjamin Tissoires
Signed-off-by: Peter Hutterer
---
Unchanged since v1
drivers/hid/hid-logitech-hidpp.c | 47 +++-
1 file changed, 34 insertions(+), 13 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 22b37a3844d1..95ba9db6e613 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -400,32 +400,53 @@ static void hidpp_prefix_name(char **name, int
name_length)
#define HIDPP_SET_LONG_REGISTER0x82
#define HIDPP_GET_LONG_REGISTER0x83
-#define HIDPP_REG_GENERAL 0x00
-
-static int hidpp10_enable_battery_reporting(struct hidpp_device *hidpp_dev)
+/**
+ * hidpp10_set_register_bit() - Sets a single bit in a HID++ 1.0 register.
+ * @hidpp_dev: the device to set the register on.
+ * @register_address: the address of the register to modify.
+ * @byte: the byte of the register to modify. Should be less than 3.
+ * Return: 0 if successful, otherwise a negative error code.
+ */
+static int hidpp10_set_register_bit(struct hidpp_device *hidpp_dev,
+ u8 register_address, u8 byte, u8 bit)
{
struct hidpp_report response;
int ret;
u8 params[3] = { 0 };
ret = hidpp_send_rap_command_sync(hidpp_dev,
- REPORT_ID_HIDPP_SHORT,
- HIDPP_GET_REGISTER,
- HIDPP_REG_GENERAL,
- NULL, 0, &response);
+ REPORT_ID_HIDPP_SHORT,
+ HIDPP_GET_REGISTER,
+ register_address,
+ NULL, 0, &response);
if (ret)
return ret;
memcpy(params, response.rap.params, 3);
- /* Set the battery bit */
- params[0] |= BIT(4);
+ params[byte] |= BIT(bit);
return hidpp_send_rap_command_sync(hidpp_dev,
- REPORT_ID_HIDPP_SHORT,
- HIDPP_SET_REGISTER,
- HIDPP_REG_GENERAL,
- params, 3, &response);
+ REPORT_ID_HIDPP_SHORT,
+ HIDPP_SET_REGISTER,
+ register_address,
+ params, 3, &response);
+}
+
+
+#define HIDPP_REG_GENERAL 0x00
+
+static int hidpp10_enable_battery_reporting(struct hidpp_device *hidpp_dev)
+{
+ return hidpp10_set_register_bit(hidpp_dev, HIDPP_REG_GENERAL, 0, 4);
+}
+
+#define HIDPP_REG_FEATURES 0x01
+
+/* On HID++ 1.0 devices, high-res scroll was called "scrolling acceleration".
*/
+static int hidpp10_enable_scrolling_acceleration(struct hidpp_device
*hidpp_dev)
+{
+ return hidpp10_set_register_bit(hidpp_dev, HIDPP_REG_FEATURES, 0, 6);
}
#define HIDPP_REG_BATTERY_STATUS 0x07
--
2.19.2
[PATCH v3 4/8] HID: input: use the Resolution Multiplier for high-resolution scrolling
Windows uses a magic number of 120 for a wheel click. High-resolution
scroll wheels are supposed to use a fraction of 120 to signal smaller
scroll steps. This is implemented by the Resolution Multiplier in the
device itself.
If the multiplier is present in the report descriptor, set it to the
logical max and then use the resolution multiplier to calculate the
high-resolution events. This is the recommendation by Microsoft, see
http://msdn.microsoft.com/en-us/windows/hardware/gg487477.aspx
Note that all mice encountered so far have a logical min/max of 0/1, so
it's a binary "yes or no" to high-res scrolling anyway.
To make userspace simpler, always enable the REL_WHEEL_HI_RES bit. Where
the device doesn't support high-resolution scrolling, the value for the
high-res data will simply be a multiple of 120 every time. For userspace,
if REL_WHEEL_HI_RES is available that is the one to be used.
Potential side-effect: a device with a Resolution Multiplier applying to
other Input items will have those items set to the logical max as well.
This cannot easily be worked around but it is doubtful such devices exist.
Signed-off-by: Peter Hutterer
---
Changes since v1:
- drop the wheel factor and calculate the hi-res value as the event comes
in. This fixes the issue with a multiplier of 16, makes the code simpler
too because we don't have to refresh anything after setting the
multiplier.
Changes since v2:
- unchanged
drivers/hid/hid-input.c | 108 ++--
include/linux/hid.h | 3 ++
2 files changed, 108 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index d6fab5798487..59a5608b8dc0 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -712,7 +712,15 @@ static void hidinput_configure_usage(struct hid_input
*hidinput, struct hid_fiel
map_abs_clear(usage->hid & 0xf);
break;
- case HID_GD_SLIDER: case HID_GD_DIAL: case HID_GD_WHEEL:
+ case HID_GD_WHEEL:
+ if (field->flags & HID_MAIN_ITEM_RELATIVE) {
+ set_bit(REL_WHEEL, input->relbit);
+ map_rel(REL_WHEEL_HI_RES);
+ } else {
+ map_abs(usage->hid & 0xf);
+ }
+ break;
+ case HID_GD_SLIDER: case HID_GD_DIAL:
if (field->flags & HID_MAIN_ITEM_RELATIVE)
map_rel(usage->hid & 0xf);
else
@@ -1012,7 +1020,10 @@ static void hidinput_configure_usage(struct hid_input
*hidinput, struct hid_fiel
case 0x22f: map_key_clear(KEY_ZOOMRESET); break;
case 0x233: map_key_clear(KEY_SCROLLUP);break;
case 0x234: map_key_clear(KEY_SCROLLDOWN); break;
- case 0x238: map_rel(REL_HWHEEL);break;
+ case 0x238: /* AC Pan */
+ set_bit(REL_HWHEEL, input->relbit);
+ map_rel(REL_HWHEEL_HI_RES);
+ break;
case 0x23d: map_key_clear(KEY_EDIT);break;
case 0x25f: map_key_clear(KEY_CANCEL); break;
case 0x269: map_key_clear(KEY_INSERT); break;
@@ -1200,6 +1211,38 @@ static void hidinput_configure_usage(struct hid_input
*hidinput, struct hid_fiel
}
+static void hidinput_handle_scroll(struct hid_usage *usage,
+ struct input_dev *input,
+ __s32 value)
+{
+ int code;
+ int hi_res, lo_res;
+
+ if (value == 0)
+ return;
+
+ if (usage->code == REL_WHEEL_HI_RES)
+ code = REL_WHEEL;
+ else
+ code = REL_HWHEEL;
+
+ /*
+* Windows reports one wheel click as value 120. Where a high-res
+* scroll wheel is present, a fraction of 120 is reported instead.
+* Our REL_WHEEL_HI_RES axis does the same because all HW must
+* adhere to the 120 expectation.
+*/
+ hi_res = value * 120/usage->resolution_multiplier;
+
+ usage->wheel_accumulated += hi_res;
+ lo_res = usage->wheel_accumulated/120;
+ if (lo_res)
+ usage->wheel_accumulated -= lo_res * 120;
+
+ input_event(input, EV_REL, code, lo_res);
+ input_event(input, EV_REL, usage->code, hi_res);
+}
+
void hidinput_hid_event(struct hid_device *hid, struct hid_field *field,
struct hid_usage *usage, __s32 value)
{
struct input_dev *input;
@@ -1262,6 +1305,12 @@ void hidinput_hid_event(struct hid_device *hid, struct
hid_field *field, struct
if ((usage->type == EV_KEY) && (usage->code == 0)) /* Key 0 is
"unassi
[PATCH v3 0/8] HID: MS and Logitech high-resolution scroll wheel support
A full explanation of why and what is in the v1, v2 patch thread here: https://lkml.org/lkml/2018/11/22/625 v3 adds a better commit messages, m560 REL_HWHEEL_HI_RES support and a patch moved in the ordering. This is a full patch sequence because Benjamin's magic scripts struggle with singular updates ;) hid-tools patches to add the tests: https://gitlab.freedesktop.org/libevdev/hid-tools/merge_requests/12 libinput support (unmerged): https://gitlab.freedesktop.org/whot/libinput/tree/wip/hi-res-scrolling If you want to 'feel' how it works, run sudo ./builddir/libinput-debug-gui and watch the green/red scroll bars. On a device with hi-res scrolling the green bar (scroll fractions) will move smoother than the red bar (wheel clicks). Tested with: - Microsoft Comfort Optical Mouse 3000 - Microsoft Sculpt Ergonomic Mouse - Microsoft Wireless Mobile Mouse 4000 - Logitech MX Anywhere 2S And a few other mice that don't have that feature, so the testing was of limited excitement. Cheers, Peter Harry Cutts (3): HID: logitech: Add function to enable HID++ 1.0 "scrolling acceleration" HID: logitech: Enable high-resolution scrolling on Logitech mice HID: logitech: Use LDJ_DEVICE macro for existing Logitech mice Peter Hutterer (5): Input: add `REL_WHEEL_HI_RES` and `REL_HWHEEL_HI_RES` HID: core: store the collections as a basic tree HID: core: process the Resolution Multiplier HID: input: use the Resolution Multiplier for high-resolution scrolling HID: logitech-hidpp: fix typo, hiddpp to hidpp Documentation/input/event-codes.rst| 21 +++- drivers/hid/hid-core.c | 174 + drivers/hid/hid-input.c| 108 +++- drivers/hid/hid-logitech-hidpp.c | 375 +++--- include/linux/hid.h| 10 ++ include/uapi/linux/input-event-codes.h | 2 + 6 files changed, 651 insertions(+), 39 deletions(-)
[PATCH v3 1/8] Input: add `REL_WHEEL_HI_RES` and `REL_HWHEEL_HI_RES`
This event code represents scroll reports from high-resolution wheels and is modelled after the approach Windows uses. The value 120 is one detent (wheel click) of movement. Mice with higher-resolution scrolling can send fractions of 120 which must be accumulated in userspace. Userspace can either wait for a full 120 to accumulate or scroll by fractions of one logical scroll movement as the events come in. 120 was picked as magic number because it has a high number of integer fractions that can be used by high-resolution wheels. For more information see https://docs.microsoft.com/en-us/previous-versions/windows/hardware/design/dn613912(v=vs.85) These new axes obsolete REL_WHEEL and REL_HWHEEL. The legacy axes are emulated by the kernel but the most accurate (and most granular) data is available through the new axes. Signed-off-by: Peter Hutterer --- No changes since v1 Documentation/input/event-codes.rst| 21 - include/uapi/linux/input-event-codes.h | 2 ++ 2 files changed, 22 insertions(+), 1 deletion(-) diff --git a/Documentation/input/event-codes.rst b/Documentation/input/event-codes.rst index a8c0873beb95..b24b5343f5eb 100644 --- a/Documentation/input/event-codes.rst +++ b/Documentation/input/event-codes.rst @@ -190,7 +190,26 @@ A few EV_REL codes have special meanings: * REL_WHEEL, REL_HWHEEL: - These codes are used for vertical and horizontal scroll wheels, -respectively. +respectively. The value is the number of detents moved on the wheel, the +physical size of which varies by device. For high-resolution wheels +this may be an approximation based on the high-resolution scroll events, +see REL_WHEEL_HI_RES. These event codes are legacy codes and +REL_WHEEL_HI_RES and REL_HWHEEL_HI_RES should be preferred where +available. + +* REL_WHEEL_HI_RES, REL_HWHEEL_HI_RES: + + - High-resolution scroll wheel data. The accumulated value 120 represents +movement by one detent. For devices that do not provide high-resolution +scrolling, the value is always a multiple of 120. For devices with +high-resolution scrolling, the value may be a fraction of 120. + +If a vertical scroll wheel supports high-resolution scrolling, this code +will be emitted in addition to REL_WHEEL or REL_HWHEEL. The REL_WHEEL +and REL_HWHEEL may be an approximation based on the high-resolution +scroll events. There is no guarantee that the high-resolution data +is a multiple of 120 at the time of an emulated REL_WHEEL or REL_HWHEEL +event. EV_ABS -- diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h index 3eb5a4c3d60a..265ef2028660 100644 --- a/include/uapi/linux/input-event-codes.h +++ b/include/uapi/linux/input-event-codes.h @@ -716,6 +716,8 @@ * the situation described above. */ #define REL_RESERVED 0x0a +#define REL_WHEEL_HI_RES 0x0b +#define REL_HWHEEL_HI_RES 0x0c #define REL_MAX0x0f #define REL_CNT(REL_MAX+1) -- 2.19.2
Re: [PATCH 0/8] HID: MS and Logitech high-resolution scroll wheel support
On Wed, Nov 28, 2018 at 03:22:14PM -0800, Harry Cutts wrote: > On Wed, 21 Nov 2018 at 22:34, Peter Hutterer wrote: > > [snip] > > Devices tested: > > - Microsoft Comfort Optical Mouse 3000 > > - Microsoft Sculpt Ergonomic Mouse > > - Microsoft Surface mouse > > - Logitech MX Anywhere 2S > > > > The following devices were tested for the HID feature and didn't have it: > > - Logitech G500s, G303 > > - Roccat Kone XTD > > - all the cheap Lenovo, HP, Dell, Logitech USB mice that come with a > > workstation that I could find in the local office > > - Etekcity something something > > - Razer Imperator > > - Microsoft Classic IntelliMouse > > - Microsoft Surface Mobile Mouse > > I just tested the patches with the Microsoft Comfort Optical Mouse > 3000. I also tested with the Microsoft Surface Precision mouse [0], > and like the Surface Mobile mouse it didn't seem to report the HID > feature (at least, it was only reporting REL_WHEEL_HI_RES changes of > 120 in evtest). IIRC that's the same mouse benjamin has and it does have the HID feature, it just ends up reporting the same number of clicks anyway so there's no visible effect. Which in itself is a good sign for the patch series, I guess ;) > For the series: > Acked-by: Harry Cutts > Verified-by: Harry Cutts thanks, much appreciated. Cheers, Peter > Harry Cutts > Chrome OS Touch/Input team > > [0]: https://microsoft.com/en-us/p/surface-precision-mouse/8qc5p0d8ddjt
Re: [PATCH] Input: synaptics - Add PNP ID for ThinkPad P50 to SMBus
On Wed, Nov 21, 2018 at 03:16:20PM -0500, Lyude Paul wrote:
> Noticed the other day the trackpoint felt different on my P50, then
> realized it was because rmi4 wasn't loading for this machine
> automatically. Suspend/resume, hibernate, and everything else seem to
> work perfectly fine on here.
>
> Signed-off-by: Lyude Paul
Acked-by: Peter Hutterer
Cheers,
Peter
> ---
> drivers/input/mouse/synaptics.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
> index 5e85f3cca867..c42813d50591 100644
> --- a/drivers/input/mouse/synaptics.c
> +++ b/drivers/input/mouse/synaptics.c
> @@ -170,6 +170,7 @@ static const char * const smbus_pnp_ids[] = {
> "LEN0048", /* X1 Carbon 3 */
> "LEN0046", /* X250 */
> "LEN004a", /* W541 */
> + "LEN005b", /* P50 */
> "LEN0071", /* T480 */
> "LEN0072", /* X1 Carbon Gen 5 (2017) - Elan/ALPS trackpoint */
> "LEN0073", /* X1 Carbon G5 (Elantech) */
> --
> 2.19.1
>
[PATCH v2 4/8] HID: input: use the Resolution Multiplier for high-resolution scrolling
Windows uses a magic number of 120 for a wheel click. High-resolution
scroll wheels are supposed to use a fraction of 120 to signal smaller
scroll steps. This is implemented by the Resolution Multiplier in the
device itself.
If the multiplier is present in the report descriptor, set it to the
logical max and then use the resolution multiplier to calculate the
high-resolution events. This is the recommendation by Microsoft, see
http://msdn.microsoft.com/en-us/windows/hardware/gg487477.aspx
Note that all mice encountered so far have a logical min/max of 0/1, so
it's a binary "yes or no" to high-res scrolling anyway.
To make userspace simpler, always enable the REL_WHEEL_HI_RES bit. Where
the device doesn't support high-resolution scrolling, the value for the
high-res data will simply be a multiple of 120 every time. For userspace,
if REL_WHEEL_HI_RES is available that is the one to be used.
Potential side-effect: a device with a Resolution Multiplier applying to
other Input items will have those items set to the logical max as well.
This cannot easily be worked around but it is doubtful such devices exist.
Signed-off-by: Peter Hutterer
---
Changes to v1:
- drop the wheel factor and calculate the hi-res value as the event comes
in. This fixes the issue with a multiplier of 16, makes the code simpler
too because we don't have to refresh anything after setting the
multiplier.
drivers/hid/hid-input.c | 108 ++--
include/linux/hid.h | 3 ++
2 files changed, 108 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index ad823a01bd65..328ce163aea8 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -709,7 +709,15 @@ static void hidinput_configure_usage(struct hid_input
*hidinput, struct hid_fiel
map_abs_clear(usage->hid & 0xf);
break;
- case HID_GD_SLIDER: case HID_GD_DIAL: case HID_GD_WHEEL:
+ case HID_GD_WHEEL:
+ if (field->flags & HID_MAIN_ITEM_RELATIVE) {
+ set_bit(REL_WHEEL, input->relbit);
+ map_rel(REL_WHEEL_HI_RES);
+ } else {
+ map_abs(usage->hid & 0xf);
+ }
+ break;
+ case HID_GD_SLIDER: case HID_GD_DIAL:
if (field->flags & HID_MAIN_ITEM_RELATIVE)
map_rel(usage->hid & 0xf);
else
@@ -1009,7 +1017,10 @@ static void hidinput_configure_usage(struct hid_input
*hidinput, struct hid_fiel
case 0x22f: map_key_clear(KEY_ZOOMRESET); break;
case 0x233: map_key_clear(KEY_SCROLLUP);break;
case 0x234: map_key_clear(KEY_SCROLLDOWN); break;
- case 0x238: map_rel(REL_HWHEEL);break;
+ case 0x238: /* AC Pan */
+ set_bit(REL_HWHEEL, input->relbit);
+ map_rel(REL_HWHEEL_HI_RES);
+ break;
case 0x23d: map_key_clear(KEY_EDIT);break;
case 0x25f: map_key_clear(KEY_CANCEL); break;
case 0x269: map_key_clear(KEY_INSERT); break;
@@ -1197,6 +1208,38 @@ static void hidinput_configure_usage(struct hid_input
*hidinput, struct hid_fiel
}
+static void hidinput_handle_scroll(struct hid_usage *usage,
+ struct input_dev *input,
+ __s32 value)
+{
+ int code;
+ int hi_res, lo_res;
+
+ if (value == 0)
+ return;
+
+ if (usage->code == REL_WHEEL_HI_RES)
+ code = REL_WHEEL;
+ else
+ code = REL_HWHEEL;
+
+ /*
+* Windows reports one wheel click as value 120. Where a high-res
+* scroll wheel is present, a fraction of 120 is reported instead.
+* Our REL_WHEEL_HI_RES axis does the same because all HW must
+* adhere to the 120 expectation.
+*/
+ hi_res = value * 120/usage->resolution_multiplier;
+
+ usage->wheel_accumulated += hi_res;
+ lo_res = usage->wheel_accumulated/120;
+ if (lo_res)
+ usage->wheel_accumulated -= lo_res * 120;
+
+ input_event(input, EV_REL, code, lo_res);
+ input_event(input, EV_REL, usage->code, hi_res);
+}
+
void hidinput_hid_event(struct hid_device *hid, struct hid_field *field,
struct hid_usage *usage, __s32 value)
{
struct input_dev *input;
@@ -1259,6 +1302,12 @@ void hidinput_hid_event(struct hid_device *hid, struct
hid_field *field, struct
if ((usage->type == EV_KEY) && (usage->code == 0)) /* Key 0 is
"unassigned", not KEY_
[PATCH v2 8/8] HID: logitech: Enable high-resolution scrolling on Logitech mice
From: Harry Cutts
There are three features used by various Logitech mice for
high-resolution scrolling: the scrolling acceleration bit in HID++ 1.0,
and the x2120 and x2121 features in HID++ 2.0 and above. This patch
supports all three, and uses the multiplier reported by the mouse for
the HID++ 2.0+ features.
The full list of product IDs of mice which support high-resolution
scrolling was provided by Logitech, but the patch was tested using the
following mice (using the Unifying receiver):
* HID++ 1.0: Anywhere MX, Performance MX
* x2120: M560
* x2121: MX Anywhere 2, MX Master 2S
This patch is a combinations of the now-reverted commits 1ff2e1a44e0,
d56ca9855bf9, 5fe2ccbef9d, 044ee89028 together with some extra bits for the
directional and timeout-based reset.
The previous patch series was in hid-input, it appears this remainder
handling is logitech-specific and was moved to hid-logitech-hidpp.c and
renamed accordingly.
Signed-off-by: Harry Cutts
Signed-off-by: Peter Hutterer
---
Changes to v1:
- get rid of the timer in favour of sched_clock()
- drop storing the multiplier and calculate value on the fly
drivers/hid/hid-logitech-hidpp.c | 292 ++-
1 file changed, 288 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 67ca587aecfa..236ed256e4e7 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -64,6 +65,14 @@ MODULE_PARM_DESC(disable_tap_to_click,
#define HIDPP_QUIRK_NO_HIDINPUTBIT(23)
#define HIDPP_QUIRK_FORCE_OUTPUT_REPORTS BIT(24)
#define HIDPP_QUIRK_UNIFYING BIT(25)
+#define HIDPP_QUIRK_HI_RES_SCROLL_1P0 BIT(26)
+#define HIDPP_QUIRK_HI_RES_SCROLL_X2120BIT(27)
+#define HIDPP_QUIRK_HI_RES_SCROLL_X2121BIT(28)
+
+/* Convenience constant to check for any high-res support. */
+#define HIDPP_QUIRK_HI_RES_SCROLL (HIDPP_QUIRK_HI_RES_SCROLL_1P0 | \
+HIDPP_QUIRK_HI_RES_SCROLL_X2120 | \
+HIDPP_QUIRK_HI_RES_SCROLL_X2121)
#define HIDPP_QUIRK_DELAYED_INIT HIDPP_QUIRK_NO_HIDINPUT
@@ -128,6 +137,25 @@ struct hidpp_battery {
bool online;
};
+/**
+ * struct hidpp_scroll_counter - Utility class for processing high-resolution
+ * scroll events.
+ * @dev: the input device for which events should be reported.
+ * @wheel_multiplier: the scalar multiplier to be applied to each wheel event
+ * @remainder: counts the number of high-resolution units moved since the last
+ * low-resolution event (REL_WHEEL or REL_HWHEEL) was sent. Should
+ * only be used by class methods.
+ * @direction: direction of last movement (1 or -1)
+ * @last_time: last event time, used to reset remainder after inactivity
+ */
+struct hidpp_scroll_counter {
+ struct input_dev *dev;
+ int wheel_multiplier;
+ int remainder;
+ int direction;
+ unsigned long long last_time;
+};
+
struct hidpp_device {
struct hid_device *hid_dev;
struct mutex send_mutex;
@@ -149,6 +177,7 @@ struct hidpp_device {
unsigned long capabilities;
struct hidpp_battery battery;
+ struct hidpp_scroll_counter vertical_wheel_counter;
};
/* HID++ 1.0 error codes */
@@ -391,6 +420,67 @@ static void hidpp_prefix_name(char **name, int name_length)
*name = new_name;
}
+/**
+ * hidpp_scroll_counter_handle_scroll() - Send high- and low-resolution scroll
+ *events given a high-resolution wheel
+ *movement.
+ * @counter: a hid_scroll_counter struct describing the wheel.
+ * @hi_res_value: the movement of the wheel, in the mouse's high-resolution
+ *units.
+ *
+ * Given a high-resolution movement, this function converts the movement into
+ * fractions of 120 and emits high-resolution scroll events for the input
+ * device. It also uses the multiplier from &struct hid_scroll_counter to
+ * emit low-resolution scroll events when appropriate for
+ * backwards-compatibility with userspace input libraries.
+ */
+static void hidpp_scroll_counter_handle_scroll(struct hidpp_scroll_counter
*counter,
+ int hi_res_value)
+{
+ int low_res_value, remainder, direction;
+ unsigned long long now, previous;
+
+ hi_res_value = hi_res_value * 120/counter->wheel_multiplier;
+ input_report_rel(counter->dev, REL_WHEEL_HI_RES, hi_res_value);
+
+ remainder = counter->remainder;
+ direction = hi_res_value > 0 ? 1 : -1;
+
+ now = sched_clock();
+ previous = counter->last_time;
+ counter->last_time = now;
+ /*
+* Reset t
Re: [PATCH 4/8] HID: input: use the Resolution Multiplier for high-resolution scrolling
On Mon, Nov 26, 2018 at 06:30:04PM -0800, Linus Torvalds wrote: > On Thu, Nov 22, 2018 at 3:28 PM Peter Hutterer > wrote: > > > > The device sends hi-res values of 4, so it should end up as REL_WHEEL_HI_RES > > 30. We are getting 28 instead which doesn't add up to a nice 120. > > I think you're just doing the math in the wrong order. > > Why don't you just do > > update = val * 120 / multiplier > > which gives you the expected "30". > > It seems you have done the "120 / multiplier" too early, and you force > that value into "wheel_factor". Don't. Do all the calculations > (including all the accumulated ones) in the original values, and only > do the "multiply by 120 and divide by multiplier" at the very end. that's such a simple solution that it almost explains why I didn't think of it... Thanks! Cheers, Peter
Re: [PATCH 4/8] HID: input: use the Resolution Multiplier for high-resolution scrolling
On Thu, Nov 22, 2018 at 04:34:05PM +1000, Peter Hutterer wrote: > Windows uses a magic number of 120 for a wheel click. High-resolution > scroll wheels are supposed to use a fraction of 120 to signal smaller > scroll steps. This is implemented by the Resolution Multiplier in the > device itself. I scooped a dirty old MS Wireless Mobile Mouse 4000 out of a mate's bin and it breaks this assumption. The resolution multiplier is 16 which isn't an integer fraction of 120. Real multiplier is 7.5. The device sends hi-res values of 4, so it should end up as REL_WHEEL_HI_RES 30. We are getting 28 instead which doesn't add up to a nice 120. Basic assumption: MS uses something other than plain 120 internally. The choices we have now are: - use 1200 or 12000 internally and divide by 10 before sending the final value - just make the evdev API use 1200 or 12000 and let userspace deal with it. much simpler. Any suggestions/comments? Cheers, Peter
[PATCH 5/8] HID: logitech-hidpp: fix typo, hiddpp to hidpp
Signed-off-by: Peter Hutterer
---
drivers/hid/hid-logitech-hidpp.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 19cc980eebce..22b37a3844d1 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -1465,7 +1465,7 @@ struct hidpp_ff_work_data {
u8 size;
};
-static const signed short hiddpp_ff_effects[] = {
+static const signed short hidpp_ff_effects[] = {
FF_CONSTANT,
FF_PERIODIC,
FF_SINE,
@@ -1480,7 +1480,7 @@ static const signed short hiddpp_ff_effects[] = {
-1
};
-static const signed short hiddpp_ff_effects_v2[] = {
+static const signed short hidpp_ff_effects_v2[] = {
FF_RAMP,
FF_FRICTION,
FF_INERTIA,
@@ -1873,11 +1873,11 @@ static int hidpp_ff_init(struct hidpp_device *hidpp, u8
feature_index)
version = bcdDevice & 255;
/* Set supported force feedback capabilities */
- for (j = 0; hiddpp_ff_effects[j] >= 0; j++)
- set_bit(hiddpp_ff_effects[j], dev->ffbit);
+ for (j = 0; hidpp_ff_effects[j] >= 0; j++)
+ set_bit(hidpp_ff_effects[j], dev->ffbit);
if (version > 1)
- for (j = 0; hiddpp_ff_effects_v2[j] >= 0; j++)
- set_bit(hiddpp_ff_effects_v2[j], dev->ffbit);
+ for (j = 0; hidpp_ff_effects_v2[j] >= 0; j++)
+ set_bit(hidpp_ff_effects_v2[j], dev->ffbit);
/* Read number of slots available in device */
error = hidpp_send_fap_command_sync(hidpp, feature_index,
--
2.19.1
[PATCH 6/8] HID: logitech: Use LDJ_DEVICE macro for existing Logitech mice
From: Harry Cutts
Signed-off-by: Harry Cutts
Reviewed-by: Benjamin Tissoires
Signed-off-by: Peter Hutterer
---
Unmodified, same as the reverted 3fe1d6bbcd1
drivers/hid/hid-logitech-hidpp.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 22b37a3844d1..146feedd9a2f 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -3088,13 +3088,11 @@ static void hidpp_remove(struct hid_device *hdev)
static const struct hid_device_id hidpp_devices[] = {
{ /* wireless touchpad */
- HID_DEVICE(BUS_USB, HID_GROUP_LOGITECH_DJ_DEVICE,
- USB_VENDOR_ID_LOGITECH, 0x4011),
+ LDJ_DEVICE(0x4011),
.driver_data = HIDPP_QUIRK_CLASS_WTP | HIDPP_QUIRK_DELAYED_INIT |
HIDPP_QUIRK_WTP_PHYSICAL_BUTTONS },
{ /* wireless touchpad T650 */
- HID_DEVICE(BUS_USB, HID_GROUP_LOGITECH_DJ_DEVICE,
- USB_VENDOR_ID_LOGITECH, 0x4101),
+ LDJ_DEVICE(0x4101),
.driver_data = HIDPP_QUIRK_CLASS_WTP | HIDPP_QUIRK_DELAYED_INIT },
{ /* wireless touchpad T651 */
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH,
@@ -3105,16 +3103,13 @@ static const struct hid_device_id hidpp_devices[] = {
USB_VENDOR_ID_LOGITECH, 0x402d),
.driver_data = HIDPP_QUIRK_DELAYED_INIT | HIDPP_QUIRK_CLASS_M560 },
{ /* Keyboard logitech K400 */
- HID_DEVICE(BUS_USB, HID_GROUP_LOGITECH_DJ_DEVICE,
- USB_VENDOR_ID_LOGITECH, 0x4024),
+ LDJ_DEVICE(0x4024),
.driver_data = HIDPP_QUIRK_CLASS_K400 },
{ /* Solar Keyboard Logitech K750 */
- HID_DEVICE(BUS_USB, HID_GROUP_LOGITECH_DJ_DEVICE,
- USB_VENDOR_ID_LOGITECH, 0x4002),
+ LDJ_DEVICE(0x4002),
.driver_data = HIDPP_QUIRK_CLASS_K750 },
- { HID_DEVICE(BUS_USB, HID_GROUP_LOGITECH_DJ_DEVICE,
- USB_VENDOR_ID_LOGITECH, HID_ANY_ID)},
+ { LDJ_DEVICE(HID_ANY_ID) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_G920_WHEEL),
.driver_data = HIDPP_QUIRK_CLASS_G920 |
HIDPP_QUIRK_FORCE_OUTPUT_REPORTS},
--
2.19.1
[PATCH 4/8] HID: input: use the Resolution Multiplier for high-resolution scrolling
Windows uses a magic number of 120 for a wheel click. High-resolution
scroll wheels are supposed to use a fraction of 120 to signal smaller
scroll steps. This is implemented by the Resolution Multiplier in the
device itself.
If the multiplier is present in the report descriptor, set it to the
logical max and then use the resolution multiplier to calculate the
high-resolution events. This is the recommendation by Microsoft, see
http://msdn.microsoft.com/en-us/windows/hardware/gg487477.aspx
Note that all mice encountered so far have a logical min/max of 0/1, so
it's a binary "yes or no" to high-res scrolling anyway.
To make userspace simpler, always enable the REL_WHEEL_HI_RES bit. Where
the device doesn't support high-resolution scrolling, the value for the
high-res data will simply be a multiple of 120 every time. For userspace,
if REL_WHEEL_HI_RES is available that is the one to be used.
Potential side-effect: a device with a Resolution Multiplier applying to
other Input items will have those items set to the logical max as well.
This cannot easily be worked around but it is doubtful such devices exist.
Signed-off-by: Peter Hutterer
---
drivers/hid/hid-input.c | 137 ++--
include/linux/hid.h | 3 +
2 files changed, 136 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index ad823a01bd65..cf0f2ae2dbf5 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -562,6 +562,17 @@ static void hidinput_update_battery(struct hid_device
*dev, int value)
}
#endif /* CONFIG_HID_BATTERY_STRENGTH */
+static void hidinput_set_wheel_factor(struct hid_usage *usage)
+{
+ /*
+* Windows reports one wheels click as value 120. Where a high-res
+* scroll wheel is present, a fraction of 120 is reported instead.
+* Our REL_WHEEL_HI_RES axis does the same because all HW must
+* adhere to the 120 expectation.
+*/
+ usage->wheel_factor = 120/usage->resolution_multiplier;
+}
+
static void hidinput_configure_usage(struct hid_input *hidinput, struct
hid_field *field,
struct hid_usage *usage)
{
@@ -709,7 +720,16 @@ static void hidinput_configure_usage(struct hid_input
*hidinput, struct hid_fiel
map_abs_clear(usage->hid & 0xf);
break;
- case HID_GD_SLIDER: case HID_GD_DIAL: case HID_GD_WHEEL:
+ case HID_GD_WHEEL:
+ if (field->flags & HID_MAIN_ITEM_RELATIVE) {
+ hidinput_set_wheel_factor(usage);
+ set_bit(REL_WHEEL, input->relbit);
+ map_rel(REL_WHEEL_HI_RES);
+ } else {
+ map_abs(usage->hid & 0xf);
+ }
+ break;
+ case HID_GD_SLIDER: case HID_GD_DIAL:
if (field->flags & HID_MAIN_ITEM_RELATIVE)
map_rel(usage->hid & 0xf);
else
@@ -1009,7 +1029,11 @@ static void hidinput_configure_usage(struct hid_input
*hidinput, struct hid_fiel
case 0x22f: map_key_clear(KEY_ZOOMRESET); break;
case 0x233: map_key_clear(KEY_SCROLLUP);break;
case 0x234: map_key_clear(KEY_SCROLLDOWN); break;
- case 0x238: map_rel(REL_HWHEEL);break;
+ case 0x238: /* AC Pan */
+ hidinput_set_wheel_factor(usage);
+ set_bit(REL_HWHEEL, input->relbit);
+ map_rel(REL_HWHEEL_HI_RES);
+ break;
case 0x23d: map_key_clear(KEY_EDIT);break;
case 0x25f: map_key_clear(KEY_CANCEL); break;
case 0x269: map_key_clear(KEY_INSERT); break;
@@ -1026,7 +1050,6 @@ static void hidinput_configure_usage(struct hid_input
*hidinput, struct hid_fiel
case 0x2ca: map_key_clear(KEY_KBDINPUTASSIST_NEXTGROUP);
break;
case 0x2cb: map_key_clear(KEY_KBDINPUTASSIST_ACCEPT); break;
case 0x2cc: map_key_clear(KEY_KBDINPUTASSIST_CANCEL); break;
-
default: map_key_clear(KEY_UNKNOWN);
}
break;
@@ -1197,6 +1220,39 @@ static void hidinput_configure_usage(struct hid_input
*hidinput, struct hid_fiel
}
+static void hidinput_handle_scroll(struct hid_device *hid,
+ struct hid_field *field,
+ struct hid_usage *usage,
+ struct input_dev *input,
+ __s32 value)
+{
+ int code;
+ struct hid_input *hidinput;
+ int hi_res, lo_res;
+
+
[PATCH 8/8] HID: logitech: Enable high-resolution scrolling on Logitech mice
From: Harry Cutts
There are three features used by various Logitech mice for
high-resolution scrolling: the scrolling acceleration bit in HID++ 1.0,
and the x2120 and x2121 features in HID++ 2.0 and above. This patch
supports all three, and uses the multiplier reported by the mouse for
the HID++ 2.0+ features.
The full list of product IDs of mice which support high-resolution
scrolling was provided by Logitech, but the patch was tested using the
following mice (using the Unifying receiver):
* HID++ 1.0: Anywhere MX, Performance MX
* x2120: M560
* x2121: MX Anywhere 2, MX Master 2S
This patch is a combinations of the now-reverted commits 1ff2e1a44e0,
d56ca9855bf9, 5fe2ccbef9d, 044ee89028 together with some extra bits for the
directional and timeout-based reset.
The previous patch series was in hid-input, it appears this remainder
handling is logitech-specific and was moved to hid-logitech-hidpp.c and
renamed accordingly.
Signed-off-by: Harry Cutts
Signed-off-by: Peter Hutterer
---
Changes to the previous version:
- this is a squash of the commits above, splitting it up after all the
changes was a tad difficult
- this looks to be a logitech-specific requirement because the firmware
can swallow events. I moved the lot to the hidpp implementation
- added directional reset together with the threshold-based REL_WHEEL
emulation trigger
- added a timeout to stop the emulation from sliding too much within the
window
This was tested on an MX Anywhere 2S, Harry, please re-test on the other
mice, thanks.
drivers/hid/hid-logitech-hidpp.c | 310 ++-
1 file changed, 306 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 67ca587aecfa..8d2a7000bf0c 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -64,6 +65,14 @@ MODULE_PARM_DESC(disable_tap_to_click,
#define HIDPP_QUIRK_NO_HIDINPUTBIT(23)
#define HIDPP_QUIRK_FORCE_OUTPUT_REPORTS BIT(24)
#define HIDPP_QUIRK_UNIFYING BIT(25)
+#define HIDPP_QUIRK_HI_RES_SCROLL_1P0 BIT(26)
+#define HIDPP_QUIRK_HI_RES_SCROLL_X2120BIT(27)
+#define HIDPP_QUIRK_HI_RES_SCROLL_X2121BIT(28)
+
+/* Convenience constant to check for any high-res support. */
+#define HIDPP_QUIRK_HI_RES_SCROLL (HIDPP_QUIRK_HI_RES_SCROLL_1P0 | \
+HIDPP_QUIRK_HI_RES_SCROLL_X2120 | \
+HIDPP_QUIRK_HI_RES_SCROLL_X2121)
#define HIDPP_QUIRK_DELAYED_INIT HIDPP_QUIRK_NO_HIDINPUT
@@ -128,6 +137,31 @@ struct hidpp_battery {
bool online;
};
+/**
+ * struct hidpp_scroll_counter - Utility class for processing high-resolution
+ * scroll events.
+ * @dev: the input device for which events should be reported.
+ * @wheel_multiplier: the scalar multiplier to be applied to wheel
+ *data as a fraction of 120. For example, if
+ *moving the wheel by one detent would result in a
+ *value of 1 in low-resolution mode but 8 in
+ *high-resolution, the multiplier is 120/8.
+ * @remainder: counts the number of high-resolution units moved since the last
+ * low-resolution event (REL_WHEEL or REL_HWHEEL) was sent. Should
+ * only be used by class methods.
+ * @direction: direction of last movement (1 or -1)
+ * @time: the timer to reset the remainder after a period of inactivity
+ */
+struct hidpp_scroll_counter {
+ struct input_dev *dev;
+ int wheel_multiplier;
+
+ int remainder;
+ int direction;
+
+ struct timer_list timer;
+};
+
struct hidpp_device {
struct hid_device *hid_dev;
struct mutex send_mutex;
@@ -149,6 +183,7 @@ struct hidpp_device {
unsigned long capabilities;
struct hidpp_battery battery;
+ struct hidpp_scroll_counter vertical_wheel_counter;
};
/* HID++ 1.0 error codes */
@@ -391,6 +426,65 @@ static void hidpp_prefix_name(char **name, int name_length)
*name = new_name;
}
+/**
+ * hidpp_scroll_counter_handle_scroll() - Send high- and low-resolution scroll
+ *events given a high-resolution wheel
+ *movement.
+ * @counter: a hid_scroll_counter struct describing the wheel.
+ * @hi_res_value: the movement of the wheel, in the mouse's high-resolution
+ *units.
+ *
+ * Given a high-resolution movement, this function converts the movement into
+ * fractions of 120 and emits high-resolution scroll events for the input
+ * device. It also uses the multiplier from &struct hid_scroll_counter to
+ * emit low-resolution scroll events when appropriate for
+ * backwards-compatibility with
[PATCH 7/8] HID: logitech: Add function to enable HID++ 1.0 "scrolling acceleration"
From: Harry Cutts
"Scrolling acceleration" is a bit of a misnomer: it doesn't deal with
acceleration at all. However, that's the name used in Logitech's spec,
so I used it here.
Signed-off-by: Harry Cutts
Reviewed-by: Benjamin Tissoires
Signed-off-by: Peter Hutterer
---
Unmodified, same as the reverted 051dc9b0
drivers/hid/hid-logitech-hidpp.c | 47 +++-
1 file changed, 34 insertions(+), 13 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 146feedd9a2f..67ca587aecfa 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -400,32 +400,53 @@ static void hidpp_prefix_name(char **name, int
name_length)
#define HIDPP_SET_LONG_REGISTER0x82
#define HIDPP_GET_LONG_REGISTER0x83
-#define HIDPP_REG_GENERAL 0x00
-
-static int hidpp10_enable_battery_reporting(struct hidpp_device *hidpp_dev)
+/**
+ * hidpp10_set_register_bit() - Sets a single bit in a HID++ 1.0 register.
+ * @hidpp_dev: the device to set the register on.
+ * @register_address: the address of the register to modify.
+ * @byte: the byte of the register to modify. Should be less than 3.
+ * Return: 0 if successful, otherwise a negative error code.
+ */
+static int hidpp10_set_register_bit(struct hidpp_device *hidpp_dev,
+ u8 register_address, u8 byte, u8 bit)
{
struct hidpp_report response;
int ret;
u8 params[3] = { 0 };
ret = hidpp_send_rap_command_sync(hidpp_dev,
- REPORT_ID_HIDPP_SHORT,
- HIDPP_GET_REGISTER,
- HIDPP_REG_GENERAL,
- NULL, 0, &response);
+ REPORT_ID_HIDPP_SHORT,
+ HIDPP_GET_REGISTER,
+ register_address,
+ NULL, 0, &response);
if (ret)
return ret;
memcpy(params, response.rap.params, 3);
- /* Set the battery bit */
- params[0] |= BIT(4);
+ params[byte] |= BIT(bit);
return hidpp_send_rap_command_sync(hidpp_dev,
- REPORT_ID_HIDPP_SHORT,
- HIDPP_SET_REGISTER,
- HIDPP_REG_GENERAL,
- params, 3, &response);
+ REPORT_ID_HIDPP_SHORT,
+ HIDPP_SET_REGISTER,
+ register_address,
+ params, 3, &response);
+}
+
+
+#define HIDPP_REG_GENERAL 0x00
+
+static int hidpp10_enable_battery_reporting(struct hidpp_device *hidpp_dev)
+{
+ return hidpp10_set_register_bit(hidpp_dev, HIDPP_REG_GENERAL, 0, 4);
+}
+
+#define HIDPP_REG_FEATURES 0x01
+
+/* On HID++ 1.0 devices, high-res scroll was called "scrolling acceleration".
*/
+static int hidpp10_enable_scrolling_acceleration(struct hidpp_device
*hidpp_dev)
+{
+ return hidpp10_set_register_bit(hidpp_dev, HIDPP_REG_FEATURES, 0, 6);
}
#define HIDPP_REG_BATTERY_STATUS 0x07
--
2.19.1
[PATCH 0/8] HID: MS and Logitech high-resolution scroll wheel support
This series enables high-resolution scrolling on some or many Microsoft mice of the last decade and Logitech mice with the required feature support. High resolution scrolling is exposed to userspace as REL_WHEEL_HI_RES and REL_HWHEEL_HI_RES. An accumulated value of 120 signals one wheel click, mice with higher granularity can send multiple values that are fractions of 120. REL_WHEEL and REL_HWHEEL are emulated for backwards compatibility. The 120 magic number comes from Windows and affects how hardware vendors build their shiny (and the use of a multiplier in the hw that is a whole fraction of 120). This series adds implementations for generic HID and for Logitech's HID++. Windows Vista added the Resolution Multiplier HID feature which gives us a multiplier that is applied (in hardware) to the wheel data. For the same physical motion and an example multiplier of 8, the hardware may: - send 8 events of value 1, or - send 1 event of value 8, or - send 8/n events of value 1 * n The multiplier is a HID Feature and should default to an effective 1 in the hardware. Windows Vista and newer set this to the logical maximum, we do the same now. It's an approved HID Feature but so far, this feature has only been found on some Microsoft mice. Logitech mice do not seem to use it and have their own HID++ protocol to apply that multiplier. Harry's patchset had previously been merged, the exact implementation was incompatible with the Microsoft bits though so it was reverted. Harry's patches in this series are adjusted accordingly but are by and large the same. Notable: The Logitech REL_WHEEL emulation cannot just hook into the HID bits. The firmware drops some events so the point when we get the REL_WHEEL event moves around. This is worked around by directional resets and a timeout-based reset. Devices tested: - Microsoft Comfort Optical Mouse 3000 - Microsoft Sculpt Ergonomic Mouse - Microsoft Surface mouse - Logitech MX Anywhere 2S The following devices were tested for the HID feature and didn't have it: - Logitech G500s, G303 - Roccat Kone XTD - all the cheap Lenovo, HP, Dell, Logitech USB mice that come with a workstation that I could find in the local office - Etekcity something something - Razer Imperator - Microsoft Classic IntelliMouse - Microsoft Surface Mobile Mouse Cheers, Peter Harry Cutts (3): HID: logitech: Use LDJ_DEVICE macro for existing Logitech mice HID: logitech: Add function to enable HID++ 1.0 "scrolling acceleration" HID: logitech: Enable high-resolution scrolling on Logitech mice Peter Hutterer (5): Input: add `REL_WHEEL_HI_RES` and `REL_HWHEEL_HI_RES` HID: core: store the collections as a basic tree HID: core: process the Resolution Multiplier HID: input: use the Resolution Multiplier for high-resolution scrolling HID: logitech-hidpp: fix typo, hiddpp to hidpp Documentation/input/event-codes.rst| 21 +++- drivers/hid/hid-core.c | 174 drivers/hid/hid-input.c| 137 - drivers/hid/hid-logitech-hidpp.c | 384 -- include/linux/hid.h| 10 ++ include/uapi/linux/input-event-codes.h | 2 + 6 files changed, 690 insertions(+), 38 deletions(-)
[PATCH 2/8] HID: core: store the collections as a basic tree
For each collection parsed, store a pointer to the parent collection
(if any). This makes it a lot easier to look up which collection(s)
any given item is part of
Signed-off-by: Peter Hutterer
---
drivers/hid/hid-core.c | 4
include/linux/hid.h| 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 5bec9244c45b..43d488a45120 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -172,6 +172,8 @@ static int open_collection(struct hid_parser *parser,
unsigned type)
collection->type = type;
collection->usage = usage;
collection->level = parser->collection_stack_ptr - 1;
+ collection->parent = parser->active_collection;
+ parser->active_collection = collection;
if (type == HID_COLLECTION_APPLICATION)
parser->device->maxapplication++;
@@ -190,6 +192,8 @@ static int close_collection(struct hid_parser *parser)
return -EINVAL;
}
parser->collection_stack_ptr--;
+ if (parser->active_collection)
+ parser->active_collection = parser->active_collection->parent;
return 0;
}
diff --git a/include/linux/hid.h b/include/linux/hid.h
index a355d61940f2..fdfda898656c 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -427,6 +427,7 @@ struct hid_local {
*/
struct hid_collection {
+ struct hid_collection *parent;
unsigned type;
unsigned usage;
unsigned level;
@@ -650,6 +651,7 @@ struct hid_parser {
unsigned int *collection_stack;
unsigned int collection_stack_ptr;
unsigned int collection_stack_size;
+ struct hid_collection *active_collection;
struct hid_device*device;
unsigned int scan_flags;
};
--
2.19.1
[PATCH 3/8] HID: core: process the Resolution Multiplier
The Resolution Multiplier is a feature report that modifies the value of
Usages within the same Logical Collection. Where set, the effective
multiplier (calculated based on the physical dimensions of the multiplier
field) affects the event value. That's done in hardware, so the values we
receive are pre-multiplied.
This was introduced for high-resolution scrolling in Windows Vista and is
commonly used on Microsoft mice.
The recommendation for the resolution multiplier is to be 1 by default. We
put some extra limits here to cap at 255. The only known usage for this is
for scroll wheels where the multiplier has to be a fraction of 120 to work
with Windows.
Signed-off-by: Peter Hutterer
---
drivers/hid/hid-core.c | 170 +
include/linux/hid.h| 5 ++
2 files changed, 175 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 43d488a45120..f41d5fe51abe 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -294,6 +294,7 @@ static int hid_add_field(struct hid_parser *parser,
unsigned report_type, unsign
field->usage[i].collection_index =
parser->local.collection_index[j];
field->usage[i].usage_index = i;
+ field->usage[i].resolution_multiplier = 1;
}
field->maxusage = usages;
@@ -947,6 +948,167 @@ struct hid_report *hid_validate_values(struct hid_device
*hid,
}
EXPORT_SYMBOL_GPL(hid_validate_values);
+static int hid_calculate_multiplier(struct hid_device *hid,
+struct hid_field *multiplier)
+{
+ int m;
+ __s32 v = *multiplier->value;
+ __s32 lmin = multiplier->logical_minimum;
+ __s32 lmax = multiplier->logical_maximum;
+ __s32 pmin = multiplier->physical_minimum;
+ __s32 pmax = multiplier->physical_maximum;
+
+ /*
+* "Because OS implementations will generally divide the control's
+* reported count by the Effective Resolution Multiplier, designers
+* should take care not to establish a potential Effective
+* Resolution Multiplier of zero."
+* HID Usage Table, v1.12, Section 4.3.1, p31
+*/
+ if (lmax - lmin == 0)
+ return 1;
+ /*
+* Handling the unit exponent is left as an exercise to whoever
+* finds a device where that exponent is not 0.
+*/
+ m = ((v - lmin)/(lmax - lmin) * (pmax - pmin) + pmin);
+ if (unlikely(multiplier->unit_exponent != 0)) {
+ hid_warn(hid,
+"unsupported Resolution Multiplier unit exponent %d\n",
+multiplier->unit_exponent);
+ }
+
+ /* There are no devices with an effective multiplier > 255 */
+ if (unlikely(m == 0 || m > 255 || m < -255)) {
+ hid_warn(hid, "unsupported Resolution Multiplier %d\n", m);
+ m = 1;
+ }
+
+ return m;
+}
+
+static void hid_apply_multiplier_to_field(struct hid_device *hid,
+ struct hid_field *field,
+ struct hid_collection
*multiplier_collection,
+ int effective_multiplier)
+{
+ struct hid_collection *collection;
+ struct hid_usage *usage;
+ int i;
+
+ /*
+* If multiplier_collection is NULL, the multiplier applies
+* to all fields in the report.
+* Otherwise, it is the Logical Collection the multiplier applies to
+* but our field may be in a subcollection of that collection.
+*/
+ for (i = 0; i < field->maxusage; i++) {
+ usage = &field->usage[i];
+
+ collection = &hid->collection[usage->collection_index];
+ while (collection && collection != multiplier_collection)
+ collection = collection->parent;
+
+ if (collection || multiplier_collection == NULL)
+ usage->resolution_multiplier = effective_multiplier;
+
+ }
+}
+
+static void hid_apply_multiplier(struct hid_device *hid,
+struct hid_field *multiplier)
+{
+ struct hid_report_enum *rep_enum;
+ struct hid_report *rep;
+ struct hid_field *field;
+ struct hid_collection *multiplier_collection;
+ int effective_multiplier;
+ int i;
+
+ /*
+* "The Resolution Multiplier control must be contained in the same
+* Logical Collection as the control(s) to which it is to be applied.
+* If no Resolution Multiplier is defined, then the Resolution
+* Multiplier defaults to 1. If more than one control exists in a
+* Logical Collection, the Resolution Multiplier is associated with
+* all controls in the collecti
[PATCH 1/8] Input: add `REL_WHEEL_HI_RES` and `REL_HWHEEL_HI_RES`
This event code represents scroll reports from high-resolution wheels and is modelled after the approach Windows uses. The value 120 is one detent (wheel click) of movement. Mice with higher-resolution scrolling can send fractions of 120 to be accumulate in userspace. Userspace can either wait for 120 to accumulate or scroll by fractions of one logical scroll movement as the events come in. For more information see https://docs.microsoft.com/en-us/previous-versions/windows/hardware/design/dn613912(v=vs.85) These new axes obsolete REL_WHEEL and REL_HWHEEL. The legacy axes are emulated but the most accurate (and most granular) data is available through the new axes. Signed-off-by: Peter Hutterer --- Documentation/input/event-codes.rst| 21 - include/uapi/linux/input-event-codes.h | 2 ++ 2 files changed, 22 insertions(+), 1 deletion(-) diff --git a/Documentation/input/event-codes.rst b/Documentation/input/event-codes.rst index a8c0873beb95..b24b5343f5eb 100644 --- a/Documentation/input/event-codes.rst +++ b/Documentation/input/event-codes.rst @@ -190,7 +190,26 @@ A few EV_REL codes have special meanings: * REL_WHEEL, REL_HWHEEL: - These codes are used for vertical and horizontal scroll wheels, -respectively. +respectively. The value is the number of detents moved on the wheel, the +physical size of which varies by device. For high-resolution wheels +this may be an approximation based on the high-resolution scroll events, +see REL_WHEEL_HI_RES. These event codes are legacy codes and +REL_WHEEL_HI_RES and REL_HWHEEL_HI_RES should be preferred where +available. + +* REL_WHEEL_HI_RES, REL_HWHEEL_HI_RES: + + - High-resolution scroll wheel data. The accumulated value 120 represents +movement by one detent. For devices that do not provide high-resolution +scrolling, the value is always a multiple of 120. For devices with +high-resolution scrolling, the value may be a fraction of 120. + +If a vertical scroll wheel supports high-resolution scrolling, this code +will be emitted in addition to REL_WHEEL or REL_HWHEEL. The REL_WHEEL +and REL_HWHEEL may be an approximation based on the high-resolution +scroll events. There is no guarantee that the high-resolution data +is a multiple of 120 at the time of an emulated REL_WHEEL or REL_HWHEEL +event. EV_ABS -- diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h index ae366b87426a..7f14d4a66c28 100644 --- a/include/uapi/linux/input-event-codes.h +++ b/include/uapi/linux/input-event-codes.h @@ -716,6 +716,8 @@ * the situation described above. */ #define REL_RESERVED 0x0a +#define REL_WHEEL_HI_RES 0x0b +#define REL_HWHEEL_HI_RES 0x0c #define REL_MAX0x0f #define REL_CNT(REL_MAX+1) -- 2.19.1
Re: Logitech high-resolution scrolling..
d one slower. third case is the opposite. The only reason this isn't very obvious is because the scroll distance is very small either way. we'd need a timeout to avoid this issue, a basic "reset remainder after N ms". - the directional change is what Linus triggered [2, 2, -2, 2, -2 ...] ← input events remainders: 0 4 r - 8 -4 -6 r + 8 2 4 r - 8 -4 -6 x x x x if you get in the right state you get to trigger the events on every small motion. Note that the issue here isn't the half-way trigger, but the missing reset. we could have the half-way trigger in place: [2, 2, -2, 2, -2 ...] ← input events 0 4 -4 0 ← reset -2 0 ← reset 2 0 ← reset x so that would work just fine, that's also what the patch below does. - fast motion can trigger some odd calculations because of the +1 added. [2, 8, -2, 2 ...] ← input events r: 0 10 r - 16 -6 -8 r + 16 (incorrect) 8 10r - 16 (incorrect) -6 xx xx xx All of these would trigger a double scroll event. Admittedly this is physically hard to trigger so it's more a theoretical concern. What's easier to trigger is: [2, 6, 2, 2 ...] ← input events 0 8 r - 16 -8 -6r + 8 (incorrect) 2 4 r - 8 -4 xx x x The xx and y events are incorrect here, total movement was 10 units but we got 3 units instead of the expected 1. Result is that on fast scrolling we may end up with the occasional extra event. The fix for this is in the patch below, by only adding the extra ±1 if we're below the multiplier, we get this instead: [2, 6, 2, 2 ...] ← input events 0 8 r - 8 0 2 4 r + 8 -4 r - 8 xx x or on a similar sequence: [2, 8, 6, 2 ...] ← input events 0 8 r - 8 0 6 4 r + 8 -2 -4 r - 8 xx x x Other issues I found with an MX Anywhere 2S is that on slow scroll and in ratchet mode we get some scroll jitter. In ratchet mode we can get this sequence if you scroll just past the notch and it snaps back: [1, 1, 1, 1, 1, 1, 1, 1, -1] That's quite easy to trigger. In free-wheel mode we may get the same for slow motion due to human finger jitter (the Anywhere 2S didn't have HW jitter, but other devices may). So a perceived-consistent scroll motion may really look like this: [1, 1, 1, 1, 1, -1, 1, 1] Hard to triggger but when it does, it feels like we're dropping events. The former isn't that much of an issue as long as the ratchet is enabled so you get the haptic feedback and we (usually) don't drop events. Finally: I reproduced the issue you mentioned with the 7/8th of a notch. A slow ratchet scroll does not always give me the same number of events per notch, there are cases where I get 7 or 9 events instead of the expected 8 (all with a hi-res value 1). With Linus patch I ended up getting weirdly ouf of sync here as to when the low res event was triggered during the motion. So my suggestion is to combine Linus' reset with your approach and use the center-point for the trigger. This gives us a few events to slide and still do the right thing, and any direction change will reset anyway. Biggest drawback is that the first event after a direction change is triggered faster than the next event. Otherwise it feels correct to me, both in free-wheeling and in ratchet mode now. The timeout I mentioned above is probably something better kept in userspace if needed. Cheers, Peter Also, WTF moment: I managed to get the mouse into a state where it would only give me 1 hi-res event per notch movement but failed to reproduce that again. >From a9cb724159cc9515ce9ee1aff15184a19731d80b Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 30 Oct 2018 14:10:53 +1000 Subject: [PATCH] HID: input: restore the hi-res scroll emulation to work on the midpoint A single notch movement does not always cause exactly $multiplier events in the hardware. Setting the trigger at the midpoint allows us to slide a few events either direction while still triggering exactly one scroll event per multiplier. Signed-off-by: Peter Hutterer --- drivers/hid/hid-input.c | 25 ++--- include/linux/hid.h | 1 + 2 files changed, 19 insertions(+), 7 deletions(-) diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c index a2f74e6adc70..a170a6823072 100644 --- a/drivers/hid/hid-input.c +++ b/drivers/hid/hid-input.c @@ -1855,7 +1855,7 @@ EXPORT_SYMBOL_GPL(hidinput_disconnect); void hid_scroll_counter_handle_scroll(struct hid_scroll_counter *counter,
Re: [PATCH] Input: synaptics - avoid using uninitialized variable when probing
On Tue, Oct 16, 2018 at 05:14:43PM -0700, Dmitry Torokhov wrote:
> synaptics_detect() does not check whether sending commands to the
> device succeeds and instead relies on getting unique data from the
> device. Let's make sure we seed entire buffer with zeroes to make sure
> we not use garbage on stack that just happen to be 0x47.
>
> Reported-by: syzbot+13cb3b01d0784e4ff...@syzkaller.appspotmail.com
> Signed-off-by: Dmitry Torokhov
doh, was just about to send out the same patch.
Reviewed-by: Peter Hutterer
Cheers,
Peter
> ---
> drivers/input/mouse/synaptics.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
> index 55d33500d55e..5e85f3cca867 100644
> --- a/drivers/input/mouse/synaptics.c
> +++ b/drivers/input/mouse/synaptics.c
> @@ -99,9 +99,7 @@ static int synaptics_mode_cmd(struct psmouse *psmouse, u8
> mode)
> int synaptics_detect(struct psmouse *psmouse, bool set_properties)
> {
> struct ps2dev *ps2dev = &psmouse->ps2dev;
> - u8 param[4];
> -
> - param[0] = 0;
> + u8 param[4] = { 0 };
>
> ps2_command(ps2dev, param, PSMOUSE_CMD_SETRES);
> ps2_command(ps2dev, param, PSMOUSE_CMD_SETRES);
> --
> 2.19.1.331.ge82ca0e54c-goog
>
>
> --
> Dmitry
Re: [PATCH] [v3] HID: add support for Apple Magic Trackpad 2
On Tue, Oct 02, 2018 at 03:39:31PM -0700, Sean O'Brien wrote:
> On Mon, Oct 1, 2018 at 1:43 AM Benjamin Tissoires
> wrote:
> >
> > [adding Peter, for the libinput question]
> >
> > On Fri, Sep 21, 2018 at 1:13 AM Sean O'Brien wrote:
> > >
> > > USB device
> > > Vendor 05ac (Apple)
> > > Device 0265 (Magic Trackpad 2)
> > > Bluetooth device
> > > Vendor 004c (Apple)
> > > Device 0265 (Magic Trackpad 2)
> > >
> > > Add support for Apple Magic Trackpad 2 over USB and bluetooth, putting
> > > the device in multi-touch mode.
> > >
> > > Signed-off-by: Claudio Mettler
> > > Signed-off-by: Marek Wyborski
> > > Signed-off-by: Sean O'Brien
> > > ---
> > >
> >
> > a few nitpcks:
> >
> > > drivers/hid/hid-ids.h| 1 +
> > > drivers/hid/hid-magicmouse.c | 149 +++
> > > 2 files changed, 134 insertions(+), 16 deletions(-)
> > >
> > > diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> > > index 5146ee029db4..bb0cd212c7cc 100644
> > > --- a/drivers/hid/hid-ids.h
> > > +++ b/drivers/hid/hid-ids.h
> > > @@ -92,6 +92,7 @@
> > > #define USB_DEVICE_ID_APPLE_MIGHTYMOUSE0x0304
> > > #define USB_DEVICE_ID_APPLE_MAGICMOUSE 0x030d
> > > #define USB_DEVICE_ID_APPLE_MAGICTRACKPAD 0x030e
> > > +#define USB_DEVICE_ID_APPLE_MAGICTRACKPAD2 0x0265
> > > #define USB_DEVICE_ID_APPLE_FOUNTAIN_ANSI 0x020e
> > > #define USB_DEVICE_ID_APPLE_FOUNTAIN_ISO 0x020f
> > > #define USB_DEVICE_ID_APPLE_GEYSER_ANSI0x0214
> > > diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c
> > > index b454c4386157..6a3a6c83e509 100644
> > > --- a/drivers/hid/hid-magicmouse.c
> > > +++ b/drivers/hid/hid-magicmouse.c
> > > @@ -54,6 +54,8 @@ module_param(report_undeciphered, bool, 0644);
> > > MODULE_PARM_DESC(report_undeciphered, "Report undeciphered multi-touch
> > > state field using a MSC_RAW event");
> > >
> > > #define TRACKPAD_REPORT_ID 0x28
> > > +#define TRACKPAD2_USB_REPORT_ID 0x02
> > > +#define TRACKPAD2_BT_REPORT_ID 0x31
> > > #define MOUSE_REPORT_ID0x29
> > > #define DOUBLE_REPORT_ID 0xf7
> > > /* These definitions are not precise, but they're close enough. (Bits
> > > @@ -91,6 +93,17 @@ MODULE_PARM_DESC(report_undeciphered, "Report
> > > undeciphered multi-touch state fie
> > > #define TRACKPAD_RES_Y \
> > > ((TRACKPAD_MAX_Y - TRACKPAD_MIN_Y) / (TRACKPAD_DIMENSION_Y / 100))
> > >
> > > +#define TRACKPAD2_DIMENSION_X (float)16000
> > > +#define TRACKPAD2_MIN_X -3678
> > > +#define TRACKPAD2_MAX_X 3934
> > > +#define TRACKPAD2_RES_X \
> > > + ((TRACKPAD2_MAX_X - TRACKPAD2_MIN_X) / (TRACKPAD2_DIMENSION_X /
> > > 100))
> > > +#define TRACKPAD2_DIMENSION_Y (float)11490
> > > +#define TRACKPAD2_MIN_Y -2478
> > > +#define TRACKPAD2_MAX_Y 2587
> > > +#define TRACKPAD2_RES_Y \
> > > + ((TRACKPAD2_MAX_Y - TRACKPAD2_MIN_Y) / (TRACKPAD2_DIMENSION_Y /
> > > 100))
> > > +
> > > /**
> > > * struct magicmouse_sc - Tracks Magic Mouse-specific data.
> > > * @input: Input device through which we report events.
> > > @@ -183,6 +196,7 @@ static void magicmouse_emit_touch(struct
> > > magicmouse_sc *msc, int raw_id, u8 *tda
> > > {
> > > struct input_dev *input = msc->input;
> > > int id, x, y, size, orientation, touch_major, touch_minor, state,
> > > down;
> > > + int pressure = 0;
> > >
> > > if (input->id.product == USB_DEVICE_ID_APPLE_MAGICMOUSE) {
> > > id = (tdata[6] << 2 | tdata[5] >> 6) & 0xf;
> > > @@ -194,6 +208,20 @@ static void magicmouse_emit_touch(struct
> > > magicmouse_sc *msc, int raw_id, u8 *tda
> > > touch_minor = tdata[4];
> > > state = tdata[7] & TOUCH_STATE_MASK;
> > > down = state != TOUCH_STATE_NONE;
> > > + } else if (input->id.product ==
> > > USB_DEVICE_ID_APPLE_MAGICTRACKPAD2) {
> > > + id = tdata[8] & 0xf;
> > > + x = (tdata[1] << 27 | tdata[0] << 19) >> 19;
> > > + y = -((tdata[3] << 30 | tdata[2] << 22 | tdata[1] << 14)
> > > >> 19);
> > > + size = tdata[6];
> > > + orientation = (tdata[8] >> 5) - 4;
> > > + touch_major = tdata[4];
> > > + touch_minor = tdata[5];
> > > + /* Add to pressure to prevent libraries such as libinput
> > > +* from ignoring low pressure touches
> > > +*/
> > > + pressure = tdata[7] + 30;
> >
> > Peter, can you have a look?
> >
> > To me, while adding this threshold, you are basically fooling
> > userspace, and we might want to come back to the raw values at some
> > point.
> > If there is a userspace problem, it has to be solved in userspace.
> >
>
> I'm fine with removing the offset. I haven't personally tested using
> libinput, but the chromium OS gesture detector I've been using can
> handle pressure values of 0.
libinput uses touch major/minor but only if a thres
[PATCH] Input: uinput - allow for max == min during input_absinfo validation
These values are inclusive, so a range of 1 requires min == max.
Signed-off-by: Peter Hutterer
---
drivers/input/misc/uinput.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index 96a887f33698..eb14ddf69346 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -410,7 +410,7 @@ static int uinput_validate_absinfo(struct input_dev *dev,
unsigned int code,
min = abs->minimum;
max = abs->maximum;
- if ((min != 0 || max != 0) && max <= min) {
+ if ((min != 0 || max != 0) && max < min) {
printk(KERN_DEBUG
"%s: invalid abs[%02x] min:%d max:%d\n",
UINPUT_NAME, code, min, max);
--
2.17.1
Re: [PATCH] Input: reserve 2 events code because of HID
On Fri, Sep 07, 2018 at 10:51:15AM +0200, Benjamin Tissoires wrote:
> From: Benjamin Tissoires
>
> Prior to commit 190d7f02ce8e ("HID: input: do not increment usages when
> a duplicate is found") from the v4.18 kernel, HID used to shift the
> event codes if a duplicate usage was found. This ended up in a situation
> where a device would export a ton of ABS_MISC+n event codes, or a ton
> of REL_MISC+n event codes.
>
> This is now fixed, however userspace needs to detect those situation.
> Fortunately, ABS_MISC+1 was never assigned a code, and so libinput
> can detect fake multitouch devices from genuine ones by checking is
> ABS_MISC+1 is set.
sorry, this isn't quite correct. we use ABS_MT_SLOT - 1 (0x2e) for the
detection of fake MT devices, i.e.
if (ABS_MT_SLOT and not ABS_MT_SLOT-1) then multitouch
That gives you up to ABS_MISC + 6 for legitimate usage. this is handled by
libevdev, not libinput directly. libevdev adjusts the various bits on "is
this device an MT device" based on whether ABS_MT_SLOT-1 is set.
I can change this to also check for (ABS_MISC and not ABS_MISC+1) but that
obviously will depend on updated libraries then. Though I guess it won't
really be an issue until we fill up the other codes up to including 0x2e
with real values and expect userspace to handle those.
None of the bits I maintain have special code for REL_MISC+n so that bit
works fine, IMO.
One request though: instead of just having the value reserved, can we make
it REL_RESERVED and ABS_RESERVED please? Or ABS_CANARY :) Much easier than
hardcoding the numeric value.
Cheers,
Peter
> Now that we have REL_WHEEL_HI_RES, libinput won't be able to differentiate
> true high res mice from some other device in a pre-v4.18 kernel.
>
> Set in stone that the ABS_MISC+1 and REL_MISC+1 are reserved and should not
> be used so userspace can properly work around those old kernels.
>
> Signed-off-by: Benjamin Tissoires
> ---
>
> Hi,
>
> while reviewing my local tree, I realize that we might want to be able
> to differentiate older kernels from new ones that export REL_WHEEL_HI_RES.
>
> I know Dmitry was against adding several REL_MISC, so I hope just moving
> REL_WHEEL_HI_RES by one and reserving the faulty event codes would be good
> this time.
>
> This patch applies on top of the branch for-4.20/logitech-highres from
> Jiri's tree. It should go through Jiri's tree as well.
>
> Cheers,
> Benjamin
>
> include/uapi/linux/input-event-codes.h | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/input-event-codes.h
> b/include/uapi/linux/input-event-codes.h
> index 29fb891ea337..30149939249a 100644
> --- a/include/uapi/linux/input-event-codes.h
> +++ b/include/uapi/linux/input-event-codes.h
> @@ -708,7 +708,12 @@
> #define REL_DIAL 0x07
> #define REL_WHEEL0x08
> #define REL_MISC 0x09
> -#define REL_WHEEL_HI_RES 0x0a
> +/*
> + * 0x0a is reserved and should not be used.
> + * It was used by HID as REL_MISC+1 and usersapce needs to detect if
> + * the next REL_* event is correct or is just REL_MISC + n.
> + */
> +#define REL_WHEEL_HI_RES 0x0b
> #define REL_MAX 0x0f
> #define REL_CNT (REL_MAX+1)
>
> @@ -745,6 +750,12 @@
>
> #define ABS_MISC 0x28
>
> +/*
> + * 0x29 is reserved and should not be used.
> + * It was used by HID as ABS_MISC+1 and usersapce needs to detect if
> + * the next ABS_* event is correct or is just ABS_MISC + n.
> + */
> +
> #define ABS_MT_SLOT 0x2f/* MT slot being modified */
> #define ABS_MT_TOUCH_MAJOR 0x30/* Major axis of touching ellipse */
> #define ABS_MT_TOUCH_MINOR 0x31/* Minor axis (omit if circular) */
> --
> 2.14.3
>
Re: [PATCH v2 1/5] Add the `REL_WHEEL_HI_RES` event code
On Thu, Aug 30, 2018 at 02:56:18PM -0700, Harry Cutts wrote: > This event code represents scroll reports from high-resolution wheels, > and will be used by future patches in this series. See the linux-input > "Reporting high-resolution scroll events" thread [0] for more details. > > [0]: https://www.spinics.net/lists/linux-input/msg57380.html > > Signed-off-by: Harry Cutts looks good to me, thanks. For the archives, the libinput issue filed for this is here: https://gitlab.freedesktop.org/libinput/libinput/issues/130 Cheers, Peter > --- > > Changes in v2: None > > Documentation/input/event-codes.rst| 11 ++- > include/uapi/linux/input-event-codes.h | 1 + > 2 files changed, 11 insertions(+), 1 deletion(-) > > diff --git a/Documentation/input/event-codes.rst > b/Documentation/input/event-codes.rst > index a8c0873beb95..cef220c176a4 100644 > --- a/Documentation/input/event-codes.rst > +++ b/Documentation/input/event-codes.rst > @@ -190,7 +190,16 @@ A few EV_REL codes have special meanings: > * REL_WHEEL, REL_HWHEEL: > >- These codes are used for vertical and horizontal scroll wheels, > -respectively. > +respectively. The value is the number of "notches" moved on the wheel, > the > +physical size of which varies by device. For high-resolution wheels > (which > +report multiple events for each notch of movement, or do not have > notches) > +this may be an approximation based on the high-resolution scroll events. > + > +* REL_WHEEL_HI_RES: > + > + - If a vertical scroll wheel supports high-resolution scrolling, this code > +will be emitted in addition to REL_WHEEL. The value is the (approximate) > +distance travelled by the user's finger, in microns. > > EV_ABS > -- > diff --git a/include/uapi/linux/input-event-codes.h > b/include/uapi/linux/input-event-codes.h > index 53fbae27b280..dad8d3890a3a 100644 > --- a/include/uapi/linux/input-event-codes.h > +++ b/include/uapi/linux/input-event-codes.h > @@ -708,6 +708,7 @@ > #define REL_DIAL 0x07 > #define REL_WHEEL0x08 > #define REL_MISC 0x09 > +#define REL_WHEEL_HI_RES 0x0a > #define REL_MAX 0x0f > #define REL_CNT (REL_MAX+1) > > -- > 2.19.0.rc0.228.g281dcd1b4d0-goog >
Re: [PATCH v1 09/10] Input: atmel_mxt_ts - tool type is ignored when slot is closed
On Tue, Jul 24, 2018 at 10:23:27AM +0200, Benjamin Tissoires wrote:
> On Tue, Jul 24, 2018 at 12:34 AM Dmitry Torokhov
> wrote:
> >
> > On Fri, Jul 20, 2018 at 10:51:21PM +0100, Nick Dyer wrote:
> > > From: Nick Dyer
> > >
> > > input_mt_report_slot_state() ignores the tool when the slot is closed.
> > > Remove the tool type from these function calls, which has caused a bit of
> > > confusion.
> >
> > Hmm, maybe we could introduce MT_TOOL_NONE or MT_TOOL_INACTIVE and get
> > rid of the 3rd parameter? It will require a bit of macro trickery for a
> > release or 2...
>
> I am not sure what would be the benefit of adding those new tools, if
> the input_mt code discards them. Do you want to forward them to the
> userspace with the release?
> This reminds me the discussion we had recently with the touchscreens
> releasing the slots with a MT_TOOL_PALM.
>
> Anyway, better include Peter as he will be using this new MT_TOOL.
thanks for the CC, would've missed this.
>From what I read this would be a helper for internal changes only, not
exposed to userspace? If so maybe it's better/easier/more readable to break
it into two functions
input_mt_open_slot(dev, MT_TOOL_FINGER)
input_mt_close_slot(dev)
This removes any ambiguity about the handling of the tool and should be a
fairly trivial search/replace. Replace the 'open/close' terminology with
whatever suits better.
Cheers,
Peter
> > > Signed-off-by: Nick Dyer
> > > ---
> > > drivers/input/touchscreen/atmel_mxt_ts.c | 5 ++---
> > > 1 file changed, 2 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
> > > b/drivers/input/touchscreen/atmel_mxt_ts.c
> > > index d7023d261458..c31af790ef84 100644
> > > --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> > > +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> > > @@ -838,8 +838,7 @@ static void mxt_proc_t9_message(struct mxt_data
> > > *data, u8 *message)
> > >* have happened.
> > >*/
> > > if (status & MXT_T9_RELEASE) {
> > > - input_mt_report_slot_state(input_dev,
> > > -MT_TOOL_FINGER, 0);
> > > + input_mt_report_slot_state(input_dev, 0, 0);
> > > mxt_input_sync(data);
> > > }
> > >
> > > @@ -855,7 +854,7 @@ static void mxt_proc_t9_message(struct mxt_data
> > > *data, u8 *message)
> > > input_report_abs(input_dev, ABS_MT_TOUCH_MAJOR, area);
> > > } else {
> > > /* Touch no longer active, close out slot */
> > > - input_mt_report_slot_state(input_dev, MT_TOOL_FINGER, 0);
> > > + input_mt_report_slot_state(input_dev, 0, 0);
> > > }
> > >
> > > data->update_input = true;
> > > --
> > > 2.17.1
> > >
> >
> > --
> > Dmitry
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Re: [PATCH v3 12/12] HID: multitouch: handle palm for touchscreens
On Thu, Jun 21, 2018 at 02:09:08PM +0200, Benjamin Tissoires wrote:
> From: Dmitry Torokhov
>
> Usually, there is no palm rejection for touchscreens. You don't rest
> your palm on the touchscreen while interacting with it.
> However, some wacom devices do so because you can rest your palm while
> interacting with the stylus.
>
> Unfortunately, the spec for touchscreens[1] is less precise than the one
> for touchpads[2]. This leads to a situation where it's 'legitimate'
> for a touchscreen to provide both tipswitch off and confidence off in the
> same report.
>
> Work around that by keeping the slot active for one frame where we report
> MT_TOOL_PALM, and then synthesizing the release event in a separate frame.
> frame
>
> Signed-off-by: Dmitry Torokhov
> [rebased and new commit message]
> Signed-off-by: Benjamin Tissoires
Acked-by: Peter Hutterer
to the series unless otherwise noted.
Cheers,
Peter
> ---
> changes in v2 (compared to Dmitry's initial submission):
> - extracted from the initial submission in a separate patch
> - rebased on top of my current series
> - add an extra input_mt_sync_frame(input); to release the single touch
> emulation
>
> no changes in v3
> ---
> drivers/hid/hid-multitouch.c | 52
> +++-
> 1 file changed, 51 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 9c708aa261ee..3a1c2d80729b 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -118,6 +118,9 @@ struct mt_application {
> int left_button_state; /* left button state */
> unsigned int mt_flags; /* flags to pass to input-mt */
>
> + unsigned long *pending_palm_slots; /* slots where we reported palm
> + * and need to release */
> +
> __u8 num_received; /* how many contacts we received */
> __u8 num_expected; /* expected last contact index */
> __u8 buttons_count; /* number of physical buttons per touchpad */
> @@ -863,6 +866,28 @@ static int mt_compute_slot(struct mt_device *td, struct
> mt_application *app,
> return input_mt_get_slot_by_key(input, *slot->contactid);
> }
>
> +static void mt_release_pending_palms(struct mt_device *td,
> + struct mt_application *app,
> + struct input_dev *input)
> +{
> + int slotnum;
> + bool need_sync = false;
> +
> + for_each_set_bit(slotnum, app->pending_palm_slots, td->maxcontacts) {
> + clear_bit(slotnum, app->pending_palm_slots);
> +
> + input_mt_slot(input, slotnum);
> + input_mt_report_slot_state(input, MT_TOOL_PALM, false);
> +
> + need_sync = true;
> + }
> +
> + if (need_sync) {
> + input_mt_sync_frame(input);
> + input_sync(input);
> + }
> +}
> +
> /*
> * this function is called when a whole packet has been received and
> processed,
> * so that it can decide what to send to the input layer.
> @@ -876,6 +901,9 @@ static void mt_sync_frame(struct mt_device *td, struct
> mt_application *app,
> input_mt_sync_frame(input);
> input_event(input, EV_MSC, MSC_TIMESTAMP, app->timestamp);
> input_sync(input);
> +
> + mt_release_pending_palms(td, app, input);
> +
> app->num_received = 0;
> app->left_button_state = 0;
>
> @@ -970,8 +998,23 @@ static int mt_process_slot(struct mt_device *td, struct
> input_dev *input,
>
> if (app->application == HID_GD_SYSTEM_MULTIAXIS)
> tool = MT_TOOL_DIAL;
> - else if (unlikely(!confidence_state))
> + else if (unlikely(!confidence_state)) {
> tool = MT_TOOL_PALM;
> + if (!active &&
> + input_mt_is_active(&mt->slots[slotnum])) {
> + /*
> + * The non-confidence was reported for
> + * previously valid contact that is also no
> + * longer valid. We can't simply report
> + * lift-off as userspace will not be aware
> + * of non-confidence, so we need to split
> + * it into 2 events: active MT_TOOL_PALM
> + * and a separate liftoff.
> + */
> + active = true;
> + set_bit(slotnum, app->pending_palm_slots);
> + }
> + }
>
> input_
Re: [PATCH v3 10/12] HID: multitouch: report MT_TOOL_PALM for non-confident touches
On Thu, Jun 21, 2018 at 02:09:06PM +0200, Benjamin Tissoires wrote:
> From: Dmitry Torokhov
>
> According to Microsoft specification [1] for Precision Touchpads (and
> Touchscreens) the devices use "confidence" reports to signal accidental
> touches, or contacts that are "too large to be a finger". Instead of
> simply marking contact inactive in this case (which causes issues if
> contact was originally proper and we lost confidence in it later, as
> this results in accidental clicks, drags, etc), let's report such
> contacts as MT_TOOL_PALM and let userspace decide what to do.
> Additionally, let's report contact size for such touches as maximum
> allowed for major/minor, which should help userspace that is not yet
> aware of MT_TOOL_PALM to still perform palm rejection.
tbh. I have a queasy feeling about this last bit. MT_TOOL_PALM has shown to
not be reliable on some devices (X1 Carbon 6th) and we mask it out on those.
Changing the major/minor means it's impossible to rely on the touch size for
palm detection once a device supports MT_TOOL_PALM.
Cheers,
Peter
>
> [1]
> https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/touchpad-windows-precision-touchpad-collection
>
> Signed-off-by: Dmitry Torokhov
> [splitted and rebased]
> Signed-off-by: Benjamin Tissoires
>
> ---
>
> changes in v2:
> - dropped the delayed release in case of palm detection. This is
> a FW bug for PTP devices, and should only happen with touchscreens
> - move input_set_abs_params(hi->input, ABS_MT_TOOL_TYPE,...) into
> its own test so other devices can add MT_QUIRK_CONFIDENCE to their
> quirks.
>
> no changes in v3
> ---
> drivers/hid/hid-multitouch.c | 30 --
> 1 file changed, 24 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index a4a274ebfbef..36c8b67bb032 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -736,6 +736,13 @@ static int mt_touch_input_mapping(struct hid_device
> *hdev, struct hid_input *hi,
> cls->name == MT_CLS_WIN_8_DUAL) &&
> field->application == HID_DG_TOUCHPAD)
> app->quirks |= MT_QUIRK_CONFIDENCE;
> +
> + if (app->quirks & MT_QUIRK_CONFIDENCE)
> + input_set_abs_params(hi->input,
> + ABS_MT_TOOL_TYPE,
> + MT_TOOL_FINGER,
> + MT_TOOL_PALM, 0, 0);
> +
> MT_STORE_FIELD(confidence_state);
> return 1;
> case HID_DG_TIPSWITCH:
> @@ -958,10 +965,12 @@ static int mt_process_slot(struct mt_device *td, struct
> input_dev *input,
> if (quirks & MT_QUIRK_HOVERING)
> inrange_state = *slot->inrange_state;
>
> - active = (*slot->tip_state || inrange_state) && confidence_state;
> + active = *slot->tip_state || inrange_state;
>
> if (app->application == HID_GD_SYSTEM_MULTIAXIS)
> tool = MT_TOOL_DIAL;
> + else if (unlikely(!confidence_state))
> + tool = MT_TOOL_PALM;
>
> input_mt_slot(input, slotnum);
> input_mt_report_slot_state(input, tool, active);
> @@ -993,11 +1002,20 @@ static int mt_process_slot(struct mt_device *td,
> struct input_dev *input,
> orientation = -azimuth;
> }
>
> - /*
> - * divided by two to match visual scale of touch
> - * for devices with this quirk
> - */
> - if (quirks & MT_QUIRK_TOUCH_SIZE_SCALING) {
> + if (unlikely(!confidence_state)) {
> + /*
> + * When reporting palm, set contact to maximum
> + * size to help userspace that does not
> + * recognize MT_TOOL_PALM to reject contacts
> + * that are too large.
> + */
> + major = input_abs_get_max(input, ABS_MT_TOUCH_MAJOR);
> + minor = input_abs_get_max(input, ABS_MT_TOUCH_MINOR);
> + } else if (quirks & MT_QUIRK_TOUCH_SIZE_SCALING) {
> + /*
> + * divided by two to match visual scale of touch
> + * for devices with this quirk
> + */
> major = major >> 1;
> minor = minor >> 1;
> }
> --
> 2.14.3
>
Re: [PATCH v3 01/12] input: add MT_TOOL_DIAL
On Thu, Jun 21, 2018 at 02:08:57PM +0200, Benjamin Tissoires wrote:
> A dial is a tool you place on a multitouch surface which reports its
> orientation or a relative angle of rotation when rotating its knob.
>
> Some examples are the Dell Totem (on the Canvas 27"), the Microsoft Dial,
> or the Griffin Powermate, though the later can't be put on a touch surface.
>
> We give some extra space to account for other types of fingers if we need
> (MT_TOOL_THUMB)
>
> Slightly change the documentation to not make it mandatory to update each
> MT_TOOL we add.
>
> Acked-by: Dmitry Torokhov
> Signed-off-by: Benjamin Tissoires
>
> ---
>
> new in v2 (extracted from previous series in its own patch)
>
> changes in v3:
> - re-insert the change in include/uapi/linux/input.h
> ---
> Documentation/input/multi-touch-protocol.rst | 12 ++--
> include/uapi/linux/input.h | 3 ++-
> 2 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/input/multi-touch-protocol.rst
> b/Documentation/input/multi-touch-protocol.rst
> index b51751a0cd5d..6be70342e709 100644
> --- a/Documentation/input/multi-touch-protocol.rst
> +++ b/Documentation/input/multi-touch-protocol.rst
> @@ -310,12 +310,12 @@ ABS_MT_TOOL_Y
> ABS_MT_TOOL_TYPE
> The type of approaching tool. A lot of kernel drivers cannot distinguish
> between different tool types, such as a finger or a pen. In such cases,
> the
> -event should be omitted. The protocol currently supports MT_TOOL_FINGER,
> -MT_TOOL_PEN, and MT_TOOL_PALM [#f2]_. For type B devices, this event is
> -handled by input core; drivers should instead use
> -input_mt_report_slot_state(). A contact's ABS_MT_TOOL_TYPE may change
> over
> -time while still touching the device, because the firmware may not be
> able
> -to determine which tool is being used when it first appears.
> +event should be omitted. The protocol currently mainly supports
> +MT_TOOL_FINGER, MT_TOOL_PEN, and MT_TOOL_PALM [#f2]_.
> +For type B devices, this event is handled by input core; drivers should
> +instead use input_mt_report_slot_state(). A contact's ABS_MT_TOOL_TYPE
> may
> +change over time while still touching the device, because the firmware
> may
> +not be able to determine which tool is being used when it first appears.
>
> ABS_MT_BLOB_ID
> The BLOB_ID groups several packets together into one arbitrarily shaped
> diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
> index 7288a7c573cc..e931b0468b6d 100644
> --- a/include/uapi/linux/input.h
> +++ b/include/uapi/linux/input.h
> @@ -273,7 +273,8 @@ struct input_mask {
> #define MT_TOOL_FINGER 0
> #define MT_TOOL_PEN 1
> #define MT_TOOL_PALM 2
> -#define MT_TOOL_MAX 2
> +#define MT_TOOL_DIAL 10
> +#define MT_TOOL_MAX 10
sorry for the late comment here: I'd prefer MAX to be greater than the
actually used highest value. This isn't strictly technically necessary
because tools *should* be able to deal with FOO == MAX but there are some
corner-cases that get more quirky. e.g. converting the string "SW_MAX" to
value is 0xf, but 0xf to name is "SW_PEN_INSERTED". Compare that to
"REL_MAX" -> 0xf -> "REL_MAX".
I know this case needs to be handled etc but not having max as an already
used value papers over some of the quirks needed.
Either way, Reviewed-by: Peter Hutterer
Cheers,
Peter
>
> /*
> * Values describing the status of a force-feedback effect
> --
> 2.14.3
>
Re: [PATCH 1/2] HID: multitouch: report MT_TOOL_PALM for non-confident touches
On Mon, Jun 04, 2018 at 04:28:01PM -0700, Dmitry Torokhov wrote: > On Tue, Jun 05, 2018 at 09:06:24AM +1000, Peter Hutterer wrote: > > On Mon, Jun 04, 2018 at 02:32:55PM -0700, Dmitry Torokhov wrote: > > > On Mon, Jun 04, 2018 at 10:59:16PM +0200, Benjamin Tissoires wrote: > > > > On Mon, Jun 4, 2018 at 8:26 PM, Dmitry Torokhov > > > > wrote: > > > > > On Mon, Jun 04, 2018 at 07:55:57PM +0200, Henrik Rydberg wrote: > > > > >> Hi Dmitry, > > > > >> > > > > >> > > > Logically, the confidence state is a property of a contact, > > > > >> > > > not a new type > > > > >> > > > of contact. Trying to use it in any other way is bound to lead > > > > >> > > > to confusion. > > > > >> > > > > > > > >> > > > Problem is that MT_TOOL_PALM has been introduced in the kernel > > > > >> > > > since > > > > >> > > > v4.0 (late 2015 by a736775db683 "Input: add MT_TOOL_PALM"). > > > > >> > > > It's been used in the Synaptics RMI4 driver since and by > > > > >> > > > hid-asus in late 2016. > > > > >> > > > I can't find any other users in the current upstream tree, but > > > > >> > > > those > > > > >> > > > two are already making a precedent and changing the semantic > > > > >> > > > is a > > > > >> > > > little bit late :/ > > > > >> > I am sorry I did not respond and lost track of this issue back > > > > >> > then, but > > > > >> > I disagree with Henrik here. While confidence is a property of > > > > >> > contact, > > > > >> > so is the type of contact and it can and will change throughout > > > > >> > life of > > > > >> > a contact, especially if we will continue adding new types, such > > > > >> > as, for > > > > >> > example, thumb. In this case the firmware can transition through > > > > >> > finger->thumb or finger->thumb->palm or finger->palm as the nature > > > > >> > of > > > > >> > contact becomes better understood. Still it is the same contact > > > > >> > and we > > > > >> > should not attempt to signal userspace differently. > > > > >> We agree that the contact should stay the same, but the fear, and I > > > > >> think > > > > >> somewhere along the blurry history of this thread, the problem was > > > > >> that > > > > >> userspace interpreted the property change as a new contact (lift > > > > >> up/double > > > > >> click/etc). Finger/thumb/palm is one set of hand properties, but > > > > >> what about > > > > >> Pen? It would be hard for an application to consider a switch from > > > > >> finger to > > > > >> pen as the same contact, which is where the natural implementation > > > > >> starts to > > > > >> diverge from the intention. > > > > > > > > > > I think the userspace has to trust our tracking ID to decide whether > > > > > it > > > > > is a same contact or not. The current issue is that kernel is forcing > > > > > tracking ID change on tool type change, and one of the 2 patches that > > > > > I > > > > > posted fixed that, allowing us to keep the tracking ID for > > > > > finger->palm > > > > > transitions. > > > > > > > > I think I missed those 2 patches, can you point a LKML link? > > > > > > Sorry, I thought I sent it out with the patch we are talking about here, > > > but I did not. See below. Note that it doe snot have any protections on > > > finger->pen transitions and I am not sure any are needed at the moment. > > > We can add them wither to MT core or to drivers if we see issues with > > > devices. > > > > > > > Also, note that libevdev discards the tracking ID change now (it > > > > shouts at the user in the logs). So that means that it will now be > > > > hard to force libevdev to trust the kernel again for the tracking ID. > > > > The current rule is: >
Re: [PATCH 1/2] HID: multitouch: report MT_TOOL_PALM for non-confident touches
gt; > > > > > > > > I think it is kernel task to not signal transitions that do not make > > > sense, such as finger->pen or palm->pen etc. > > > > I fully agree, though there is currently no such guard in the kernel > > (maybe it's part of your series). I am worried about the RMI4 F12 > > driver that automatically forward the info from the firmware, so if > > the firmware does something crazy, it will be exported to user space. > > But I guess it might be better to treat that on a per driver basis. > > Yeah, I think so. > > > > > > > > >> > > >> > We could introduce the ABS_MT_CONFIDENCE (0/1 or even 0..n range), to > > >> > complement ABS_MT_TOOL, but that would not really solve the issue with > > >> > Wacom firmware (declaring contact non-confident and releasing it right > > >> > away) and given MS explanation of the confidence as "contact is too > > >> > big" > > >> > MT_TOOL_PALM fits it perfectly. > > >> Indeed, the Wacom firmware seems to need some special handling, which > > >> should > > >> be fine by everyone. I do think it would make sense to add > > >> ABS_MT_TOOL_TOO_BIG, or something, and use it if it exists. This would > > >> apply > > > > Except we are already running out of ABS_* axes. > > Sorry, meants MT_TOOL_TO_BIG, not a new axis. bikeshed: MT_TOOL_IGNORE is a more generic name and does not imply size. A pen that's lying on its side doesn't have a size but should still be ignored. > > > > >> also to a pen lying down on a touchpad, for instance. > > > > > > OK, I can see that for Pens, if we have firmware that would recognize > > > such condition, it would be weird to report PALM. We could indeed have > > > ABS_MT_TOOL_TOO_BIG, but on the other hand it is still a pen (as long as > > > the hardware can recognize it as such). Maybe we'd be better off just > > > having userspace going by contact size for pens. Peter, any suggestions > > > here? > > > > I don't think we have size handling in the tablet implementation in > > libinput. I do not see it as a big issue to add such axes from a > > libinput point of view. However, there is no existing hardware that > > would provide such information, so I guess this will be a 'no' until > > actual hardware comes in. correct on all counts :) > > Also note that the MT_TOOL_PEN implementation is limited (even > > non-existant if I remember correctly). Peter and I do not have access > > to any device that support such multi pen, so AFAICT, there is no code > > to handle this in libinput. Yep, correct. On this note: libinput very much follows a "no hardware, no implementation" rule. I played the game of trying to support everything in a generic manner with the X drivers and it's a nightmare to maintain. libinput instead takes a use case and tries to make it sensible - but for that to work we need to know both the hardware and the use-cases. That's why tablet handling coming out of libinput is very different to the handling we have in X but, afaict, everyone is better off for it so far. This means that if you give me a MT_TOOL_FINGER → MT_TOOL_PEN transition, I'll handle it, but only after you also give me the use-case for it and the promise of real devices that need it. > > One last point from libinput, the pen device would need to be on its > > separate kernel node for the protocol to be smoothly handled. So > > basically, even the transition from MT_TOOL_FINGER to MT_TOOL_PEN > > would not be handled properly right now. The Pen event will be treated > > as a touch. > > I think normally pen and touch a separate controllers, so we have that > going for us... Side-effect of this is: the tablet interface doesn't handle touch at all because it didn't need to yet. So while technically possible, it requires a fair bit of re-arranging. > Input: do not assign new tracking ID when changing tool type > > From: Dmitry Torokhov > > We allow changing tool type (from MT_TOOL_FINGER to MT_TOOL_PALM) so we > should not be forcing new tracking ID for the slot. > > Signed-off-by: Dmitry Torokhov Reviewed-by: Peter Hutterer Cheers, Peter > --- > drivers/input/input-mt.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/input/input-mt.c b/drivers/input/input-mt.c > index a1bbec9cda8d4..7ca4b318ed419 100644 > --- a/drivers/input/input-mt.c > +++ b/drivers/input/input-mt.c > @@ -151,7 +151,7 @@ void input_mt_report_slot_state(struct input_dev *dev, > } > > id = input_mt_get_value(slot, ABS_MT_TRACKING_ID); > - if (id < 0 || input_mt_get_value(slot, ABS_MT_TOOL_TYPE) != tool_type) > + if (id < 0) > id = input_mt_new_trkid(mt); > > input_event(dev, EV_ABS, ABS_MT_TRACKING_ID, id); > > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Re: [PATCH 1/2] HID: multitouch: report MT_TOOL_PALM for non-confident touches
On Mon, Jun 04, 2018 at 02:19:44PM -0700, Dmitry Torokhov wrote: > On Mon, Jun 04, 2018 at 10:42:31PM +0200, Benjamin Tissoires wrote: > > On Mon, Jun 4, 2018 at 7:33 PM, Dmitry Torokhov > > wrote: > > > On Mon, Jun 04, 2018 at 03:18:12PM +0200, Benjamin Tissoires wrote: > > >> On Fri, Jun 1, 2018 at 8:43 PM, Dmitry Torokhov > > >> wrote: > > >> > On Fri, Jun 01, 2018 at 04:16:09PM +0200, Benjamin Tissoires wrote: > > >> >> On Fri, Aug 11, 2017 at 2:44 AM, Dmitry Torokhov > > >> >> wrote: > > >> >> > According to Microsoft specification [1] for Precision Touchpads > > >> >> > (and > > >> >> > Touchscreens) the devices use "confidence" reports to signal > > >> >> > accidental > > >> >> > touches, or contacts that are "too large to be a finger". Instead of > > >> >> > simply marking contact inactive in this case (which causes issues if > > >> >> > contact was originally proper and we lost confidence in it later, as > > >> >> > this results in accidental clicks, drags, etc), let's report such > > >> >> > contacts as MT_TOOL_PALM and let userspace decide what to do. > > >> >> > Additionally, let's report contact size for such touches as maximum > > >> >> > allowed for major/minor, which should help userspace that is not yet > > >> >> > aware of MT_TOOL_PALM to still perform palm rejection. > > >> >> > > > >> >> > An additional complication, is that some firmwares do not report > > >> >> > non-confident touches as active. To cope with this we delay release > > >> >> > of > > >> >> > such contact (i.e. if contact was active we first report it as still > > >> >> > active MT+TOOL_PALM and then synthesize the release event in a > > >> >> > separate > > >> >> > frame). > > >> >> > > >> >> I am not sure I agree with this part. The spec says that "Once a > > >> >> device has determined that a contact is unintentional, it should clear > > >> >> the confidence bit for that contact report and all subsequent > > >> >> reports." > > >> >> So in theory the spec says that if a touch has been detected as a > > >> >> palm, the flow of events should not stop (tested on the PTP of the > > >> >> Dell XPS 9360). > > >> >> > > >> >> However, I interpret a firmware that send (confidence 1, tip switch 1) > > >> >> and then (confidence 0, tip switch 0) a simple release, and the > > >> >> confidence bit should not be relayed. > > >> > > > >> > This unfortunately leads to false clicks: you start with finger, so > > >> > confidence is 1, then you transition the same touch to palm (use your > > >> > thumb and "roll" your hand until heel of it comes into contact with the > > >> > screen). The firmware reports "no-confidence" and "release" in the same > > >> > report and userspace seeing release does not pay attention to > > >> > confidence > > >> > (i.e. it does exactly "simple release" logic) and this results in UI > > >> > interpreting this as a click. With splitting no-confidence > > >> > (MT_TOOL_PALM) and release event into separate frames we help userspace > > >> > to recognize that the contact should be discarded. > > >> > > >> After further thoughts, I would consider this to be a firmware bug, > > >> and not how the firmware is supposed to be reporting palm. > > >> For the precision touchpads, the spec says that the device "should > > >> clear the confidence bit for that contact report and all subsequent > > >> reports.". And it is how the Dell device I have here reports palms. > > >> The firmware is not supposed to cut the event stream. > > >> > > >> There is a test for that: > > >> https://docs.microsoft.com/en-us/previous-versions/windows/hardware/hck/dn456905%28v%3dvs.85%29 > > >> which tells me that I am right here for PTP. > > >> > > >> The touchscreen spec is blurrier however. > > > > > > OK, that is great to know. > > > > > >> > > >> > > > >> >> > > >> >> Do you have any precise example of reports where you need that > > >> >> feature? > > >> > > > >> > It was observed on Pixelbooks which use Wacom digitizers IIRC. > > >> > > >> Pixelbooks + Wacom means that it was likely a touchscreen. I am right > > >> guessing the device did not went through Microsoft certification > > >> process? > > > > > > That would be correct ;) At least the firmware that is shipping with > > > Pixlebooks hasn't, I do now if anyone else sourced these Wacom parts for > > > their MSWin devices. > > > > > >> > > >> I am in favor of splitting the patch in 2. One for the generic > > >> processing of confidence bit, and one for this spurious release. For > > >> the spurious release, I'm more in favor of explicitly quirking the > > >> devices in need of such quirk. > > > > > > Hmm, I am not sure about having specific quirk. It will be hard for > > > users to accurately diagnose the issue if firmware is broken in this way > > > so we could add a new quirk for a new device. > > > > One thing we can do is keep the quirked mechanism as default in > > hid-multitouch, but remove it in hid-core. If people need the quirk, > > they can just use hid-multit
Re: [PATCH 1/2] HID: multitouch: report MT_TOOL_PALM for non-confident touches
Hi Dmitry,
On Thu, Aug 10, 2017 at 05:44:59PM -0700, Dmitry Torokhov wrote:
> According to Microsoft specification [1] for Precision Touchpads (and
> Touchscreens) the devices use "confidence" reports to signal accidental
> touches, or contacts that are "too large to be a finger". Instead of
> simply marking contact inactive in this case (which causes issues if
> contact was originally proper and we lost confidence in it later, as
> this results in accidental clicks, drags, etc), let's report such
> contacts as MT_TOOL_PALM and let userspace decide what to do.
> Additionally, let's report contact size for such touches as maximum
> allowed for major/minor, which should help userspace that is not yet
> aware of MT_TOOL_PALM to still perform palm rejection.
>
> An additional complication, is that some firmwares do not report
> non-confident touches as active. To cope with this we delay release of
> such contact (i.e. if contact was active we first report it as still
> active MT+TOOL_PALM and then synthesize the release event in a separate
> frame).
>
> [1]
> https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/touchpad-windows-precision-touchpad-collection
>
> Signed-off-by: Dmitry Torokhov
This one popped up again in a bug report [1] and it looks like it never
got merged. fwiw, libinput does support ABS_MT_TOOL_PALM for touchpads as of
1.8.0 and just releasing the touch causes fake taps. So you have the green
light from me to merge this :)
Cheers,
Peter
[1] https://bugs.freedesktop.org/show_bug.cgi?id=106716
> ---
> drivers/hid/hid-multitouch.c | 86
> +++-
> 1 file changed, 77 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 440b999304a5..c28defe50a10 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -114,6 +114,8 @@ struct mt_device {
> struct timer_list release_timer;/* to release sticky fingers */
> struct mt_fields *fields; /* temporary placeholder for storing the
> multitouch fields */
> + unsigned long *pending_palm_slots; /* slots where we reported palm
> + and need to release */
> unsigned long mt_io_flags; /* mt flags (MT_IO_FLAGS_*) */
> int cc_index; /* contact count field index in the report */
> int cc_value_index; /* contact count value index in the field */
> @@ -543,8 +545,12 @@ static int mt_touch_input_mapping(struct hid_device
> *hdev, struct hid_input *hi,
> case HID_DG_CONFIDENCE:
> if ((cls->name == MT_CLS_WIN_8 ||
> cls->name == MT_CLS_WIN_8_DUAL) &&
> - field->application == HID_DG_TOUCHPAD)
> + field->application == HID_DG_TOUCHPAD) {
> cls->quirks |= MT_QUIRK_CONFIDENCE;
> + input_set_abs_params(hi->input,
> + ABS_MT_TOOL_TYPE,
> + MT_TOOL_FINGER, MT_TOOL_PALM, 0, 0);
> + }
> mt_store_field(usage, td, hi);
> return 1;
> case HID_DG_TIPSWITCH:
> @@ -657,6 +663,7 @@ static void mt_complete_slot(struct mt_device *td, struct
> input_dev *input)
>
> if (td->curvalid || (td->mtclass.quirks & MT_QUIRK_ALWAYS_VALID)) {
> int active;
> + int tool;
> int slotnum = mt_compute_slot(td, input);
> struct mt_slot *s = &td->curdata;
> struct input_mt *mt = input->mt;
> @@ -671,24 +678,56 @@ static void mt_complete_slot(struct mt_device *td,
> struct input_dev *input)
> return;
> }
>
> + active = s->touch_state || s->inrange_state;
> +
> if (!(td->mtclass.quirks & MT_QUIRK_CONFIDENCE))
> s->confidence_state = 1;
> - active = (s->touch_state || s->inrange_state) &&
> - s->confidence_state;
> +
> + if (likely(s->confidence_state)) {
> + tool = MT_TOOL_FINGER;
> + } else {
> + tool = MT_TOOL_PALM;
> + if (!active &&
> + input_mt_is_active(&mt->slots[slotnum])) {
> + /*
> + * The non-confidence was reported for
> + * previously valid contact that is also no
> + * longer valid. We can't simply report
> + * lift-off as userspace will not be aware
> + * of non-confidence, so we need to split
> + * it into 2 events: active MT_TOO
Re: [PATCH] HID: rmi: use HID_QUIRK_NO_INPUT_SYNC
On Fri, May 25, 2018 at 02:51:06PM +0200, Benjamin Tissoires wrote:
> When we receive a RMI4 report, we should not unconditionally send an
> input_sync event. Instead, we should let the rmi4 transport layer do it
> for us.
>
> This fixes a situation where we might receive X in a report and the rest
> in a subsequent one. And this messes up user space.
>
> Link: https://bugs.freedesktop.org/show_bug.cgi?id=100436
>
> Signed-off-by: Benjamin Tissoires
> ---
yes please!
Acked-by: Peter Hutterer
Cheers,
Peter
>
> Hi,
>
> Oscar, do you mind if we add your "Tested-by: Oscar Morante "?
>
> Andrew, can you check for any sides effects please?
>
> Cheers,
> Benjamin
>
> drivers/hid/hid-rmi.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
> index 9c9362149641..9e33165250a3 100644
> --- a/drivers/hid/hid-rmi.c
> +++ b/drivers/hid/hid-rmi.c
> @@ -413,6 +413,24 @@ static int rmi_event(struct hid_device *hdev, struct
> hid_field *field,
> return 0;
> }
>
> +static void rmi_report(struct hid_device *hid, struct hid_report *report)
> +{
> + struct hid_field *field = report->field[0];
> +
> + if (!(hid->claimed & HID_CLAIMED_INPUT))
> + return;
> +
> + switch (report->id) {
> + case RMI_READ_DATA_REPORT_ID:
> + /* fall-through */
> + case RMI_ATTN_REPORT_ID:
> + return;
> + }
> +
> + if (field && field->hidinput && field->hidinput->input)
> + input_sync(field->hidinput->input);
> +}
> +
> #ifdef CONFIG_PM
> static int rmi_suspend(struct hid_device *hdev, pm_message_t message)
> {
> @@ -637,6 +655,7 @@ static int rmi_probe(struct hid_device *hdev, const
> struct hid_device_id *id)
> hid_set_drvdata(hdev, data);
>
> hdev->quirks |= HID_QUIRK_NO_INIT_REPORTS;
> + hdev->quirks |= HID_QUIRK_NO_INPUT_SYNC;
>
> ret = hid_parse(hdev);
> if (ret) {
> @@ -744,6 +763,7 @@ static struct hid_driver rmi_driver = {
> .remove = rmi_remove,
> .event = rmi_event,
> .raw_event = rmi_raw_event,
> + .report = rmi_report,
> .input_mapping = rmi_input_mapping,
> .input_configured = rmi_input_configured,
> #ifdef CONFIG_PM
> --
> 2.14.3
>
Re: [PATCH] Input: leds - fix out of bound access
On Fri, Apr 06, 2018 at 11:12:42AM -0700, Dmitry Torokhov wrote:
> UI_SET_LEDBIT ioctl() causes the following KASAN splat when used with
> led > LED_CHARGING:
>
> [ 1274.663418] BUG: KASAN: slab-out-of-bounds in
> input_leds_connect+0x611/0x730 [input_leds]
> [ 1274.663426] Write of size 8 at addr 88003377b2c0 by task
> ckb-next-daemon/5128
>
> This happens because we were writing to the led structure before making
> sure that it exists.
>
> Reported-by: Tasos Sahanidis
> Tested-by: Tasos Sahanidis
> Cc: sta...@vger.kernel.org
> Signed-off-by: Dmitry Torokhov
Reviewed-by: Peter Hutterer
Cheers,
Peter
> ---
> drivers/input/input-leds.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/input/input-leds.c b/drivers/input/input-leds.c
> index 766bf26601163..5f04b2d946350 100644
> --- a/drivers/input/input-leds.c
> +++ b/drivers/input/input-leds.c
> @@ -88,6 +88,7 @@ static int input_leds_connect(struct input_handler *handler,
> const struct input_device_id *id)
> {
> struct input_leds *leds;
> + struct input_led *led;
> unsigned int num_leds;
> unsigned int led_code;
> int led_no;
> @@ -119,14 +120,13 @@ static int input_leds_connect(struct input_handler
> *handler,
>
> led_no = 0;
> for_each_set_bit(led_code, dev->ledbit, LED_CNT) {
> - struct input_led *led = &leds->leds[led_no];
> + if (!input_led_info[led_code].name)
> + continue;
>
> + led = &leds->leds[led_no];
> led->handle = &leds->handle;
> led->code = led_code;
>
> - if (!input_led_info[led_code].name)
> - continue;
> -
> led->cdev.name = kasprintf(GFP_KERNEL, "%s::%s",
> dev_name(&dev->dev),
> input_led_info[led_code].name);
> --
> 2.17.0.484.g0c8726318c-goog
Re: [PATCH 0/7] HID core and multitouch fixups
On Tue, Mar 20, 2018 at 12:04:44PM +0100, Benjamin Tissoires wrote: > Hi, > > Patches 1 and 2 are related to the Razer Blade Stealth that has some dead zone > near the edges of the touchpad. > Patches 3 was previously sent and reviewed by Dmitry and he suggested patch 4 > at the time. > Patches 5..7 are cleanups I realized while trying to merge hid-multitouch > into hid-core, so that other drivers could reuse the hid-mt logic (but it's > not that easy I must confess). Series: Acked-by: Peter Hutterer Cheers, Peter > > Cheers, > Benjamin > > Benjamin Tissoires (7): > HID: multitouch: export a quirk for the button handling of touchpads > HID: multitouch: remove dead zones of Razer Blade Stealth > HID: use BIT macro instead of plain integers for flags > HID: use BIT() macro for quirks too > HID: core: remove the need for HID_QUIRK_NO_EMPTY_INPUT > HID: multitouch: do not set HID_QUIRK_NO_INIT_REPORTS > HID: core: reset the quirks before calling probe again > > drivers/hid/hid-asus.c | 3 +- > drivers/hid/hid-core.c | 2 ++ > drivers/hid/hid-input.c | 10 +++ > drivers/hid/hid-multitouch.c | 61 - > drivers/hid/hid-uclogic.c| 1 - > include/linux/hid.h | 65 > ++-- > 6 files changed, 65 insertions(+), 77 deletions(-) > > -- > 2.14.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Re: [RFC PATCH] input: Add disable sysfs entry for every input device
On Sat, Feb 17, 2018 at 10:19:14PM +0100, Pavel Machek wrote: > Hi! > > > > > > So, do you mean to implement this "disable" action as ioctl for > > > > > particular /dev/input/event* device (instead of sysfs entry)? > > > > > > > > Yes, so the device can be powered down without the device node being > > > > closed and made unavailable. I don't know whether that's something > > > > that's already possible for all cases, but there's already > > > > opportunistic in a lot of drivers and subsystems. > > > > > > > > This opens up a whole new wave of potential problems, but it's a more > > > > generally useful mechanism, I would think. > > > > > > Ok. How should API for this ioctl looks like? And do you have an idea > > > for name of that ioctl? > > > > > > Dmitry, what do you think about it? It is acceptable for you? > > > > first: sysfs files are pretty terrible because writing to them requires root > > and we don't have the benefit of logind. so for any sysfs toggle expect > > a nicely integrated userspace solution to be less than optimal. > > Well, you can chmod / chown sysfs files. and that's what I meant by "less than optimal" :) you're either chmodding, or suid, or any of the other solutions that aren't really good in the long run. > > besides: 99% of the above is figuring out the policy *when* to disable the > > device. disabling it is trivial by just closing the evdev nodes and tbh I > > don't think we (in userspace) should care about whether the device is > > powered down or now, it should be the default assumption that it is powered > > down when not in use. > > > > for the cases where you must keep the device open but you don't want > > events, > > EVIOCSMASK is likely the best solution. improving the kernel so it powers > > down the device when the mask excludes all events (and there are no other > > listeners) could be an interesting task. > > But yes, that sounds like an idea. > > BTW in the meantime, someone added this to pmos wiki... this should > solve some of my problems. > > Best regards, > Pavel > > > > FILE=~/.screenoff > if [ -f $FILE ]; then > xinput set-prop 8 "Device Enabled" 1 > xinput set-prop 6 "Device Enabled" 1 > xinput set-prop 9 "Device Enabled" 1 > xset dpms force on > rm ~/.screenoff > else > xinput set-prop 8 "Device Enabled" 0 > xinput set-prop 6 "Device Enabled" 0 > xinput set-prop 9 "Device Enabled" 0 > xset dpms force off > touch ~/.screenoff > fi xinput can resolve device names, using device ids is likely to cause upset. http://who-t.blogspot.com/2016/07/xinput-resolves-device-names-and.html Cheers, Peter
Re: ALPS Trackpoint & pressure
On Fri, Feb 09, 2018 at 12:21:41AM +0100, Pali Rohár wrote: > On Tuesday 06 February 2018 10:29:47 Peter Hutterer wrote: > > On Mon, Feb 05, 2018 at 02:49:55PM -0800, Dmitry Torokhov wrote: > > > On Sun, Feb 04, 2018 at 04:08:39PM +0100, Pali Rohár wrote: > > > > Hi! Now playing again with trackpoint connected to ALPS rushmore > > > > touchpad and I'm seeking a nice feature. Via ALPS PS/2 protocol it > > > > reports pressure of trackpoint. Parser for it is already implemented in > > > > alps.c and value is assigned to variable "z". When I just move > > > > trackpoint z is zero, when I push trackpoint while moving, then z is > > > > number higher, maximally 32. Variable "z" is set, but unused. > > > > > > > > Do we have some input interface which can be used to report this > > > > pressure of trackpoint to userspace? I can use this feature e.g. as > > > > additional button... > > > > > > We could either do the conversion in kernel and emit BTN_LEFT, or > > > report ABS_PRESSURE and see if userspace will be able to handle > > > REL_X/REL_Y/ABS_PRESSURE device. > > > > > > Adding Peter. > > > > judging by trackpoint history, I'd leave the pressure->click conversion to > > userspace because every trackpoint may need a different threshold setting. > > "easier" to have this in userspace with dmi matches etc. plus, converting to > > BTN_LEFT in the kernel means we cannot use it as a separate interaction > > anymore. > > Also BTN_LEFT is already reported when left button under trackpoint is > pressed. Therefore it would not be possible to distinguish between > trackpoint "press" and real left button press. yep, that's what I meant with "we cannot use it as separate interaction", we'd have no way to know how the click was generated. > > > That aside, I think exporting ABS_PRESSURE is fine, that's what it's there > > for. Nothing will use it for now though, tbh not sure yet how that would be > > exported from libinput. but worth filing a bug for, please assign it to me. > > Ok, so ABS_PRESSURE? Also then question is, how to report minimal and > maximal (possible) value? If we are going to "standardize" API for it, > we should also define min/max values, so userspace would be able to > normalize this pressure event. I can imagine that some devices can > report 8bit value, but ALPS rushmore reports only 5bit value. tbh, I'm not putting my hopes on this being an accurate range ever. So what's likely going to happen is that you pick a best-guess min/max for the kernel and then we have dmi-based overrides for every single trackpoint in userspace to tell us what a realistic threshold value for a click is and what the actual min/max ranges is. This is relatively easy to measure in userspace, we can pop it into 60-evdev.hwdb to override the min/max and ship the threshold values as libinput-specific files. It's awful, but most likely the best we can do. But hey, at least a min of 0 will be accurate ;) Cheers, Peter
Re: ALPS Trackpoint & pressure
On Mon, Feb 05, 2018 at 02:49:55PM -0800, Dmitry Torokhov wrote: > On Sun, Feb 04, 2018 at 04:08:39PM +0100, Pali Rohár wrote: > > Hi! Now playing again with trackpoint connected to ALPS rushmore > > touchpad and I'm seeking a nice feature. Via ALPS PS/2 protocol it > > reports pressure of trackpoint. Parser for it is already implemented in > > alps.c and value is assigned to variable "z". When I just move > > trackpoint z is zero, when I push trackpoint while moving, then z is > > number higher, maximally 32. Variable "z" is set, but unused. > > > > Do we have some input interface which can be used to report this > > pressure of trackpoint to userspace? I can use this feature e.g. as > > additional button... > > We could either do the conversion in kernel and emit BTN_LEFT, or > report ABS_PRESSURE and see if userspace will be able to handle > REL_X/REL_Y/ABS_PRESSURE device. > > Adding Peter. judging by trackpoint history, I'd leave the pressure->click conversion to userspace because every trackpoint may need a different threshold setting. "easier" to have this in userspace with dmi matches etc. plus, converting to BTN_LEFT in the kernel means we cannot use it as a separate interaction anymore. That aside, I think exporting ABS_PRESSURE is fine, that's what it's there for. Nothing will use it for now though, tbh not sure yet how that would be exported from libinput. but worth filing a bug for, please assign it to me. Cheers, Peter
Re: [RFC PATCH] input: Add disable sysfs entry for every input device
On Wed, Jan 03, 2018 at 10:31:33AM +0100, Pali Rohár wrote: > On Wednesday 03 January 2018 02:47:29 Bastien Nocera wrote: > > On Tue, 2018-01-02 at 22:54 +0100, Pali Rohár wrote: > > > On Wednesday 04 January 2017 15:37:35 Bastien Nocera wrote: > > > > I don't doubt that the use cases should be catered for, I > > > > essentially > > > > did that same work without kernel changes for GNOME. What I doubt > > > > is > > > > the fuzzy semantics, the fact that the device is kept opened but no > > > > data is sent (that's not power saving), that whether users are > > > > revoked > > > > or should be revoked isn't clear, and that the goal is basically to > > > > work around stupid input handling when at the console. When running > > > > a > > > > display manager, this is all avoided. > > > > > > > > If this were to go through, then the semantics and behaviour needs > > > > to > > > > be better explained, power saving actually made possible, and make > > > > sure > > > > that libinput can proxy that state to the users on the console. Or > > > > an > > > > ioctl added to the evdev device to disable them. > > > > > > So, do you mean to implement this "disable" action as ioctl for > > > particular /dev/input/event* device (instead of sysfs entry)? > > > > Yes, so the device can be powered down without the device node being > > closed and made unavailable. I don't know whether that's something > > that's already possible for all cases, but there's already > > opportunistic in a lot of drivers and subsystems. > > > > This opens up a whole new wave of potential problems, but it's a more > > generally useful mechanism, I would think. > > Ok. How should API for this ioctl looks like? And do you have an idea > for name of that ioctl? > > Dmitry, what do you think about it? It is acceptable for you? first: sysfs files are pretty terrible because writing to them requires root and we don't have the benefit of logind. so for any sysfs toggle expect a nicely integrated userspace solution to be less than optimal. besides: 99% of the above is figuring out the policy *when* to disable the device. disabling it is trivial by just closing the evdev nodes and tbh I don't think we (in userspace) should care about whether the device is powered down or now, it should be the default assumption that it is powered down when not in use. for the cases where you must keep the device open but you don't want events, EVIOCSMASK is likely the best solution. improving the kernel so it powers down the device when the mask excludes all events (and there are no other listeners) could be an interesting task. right now, I really question the need for another ioctl. Cheers, Peter
Re: [RFC PATCH] input: Add disable sysfs entry for every input device
On Thu, Jan 05, 2017 at 01:48:08PM +0100, Pali Rohár wrote: > On Wednesday 04 January 2017 15:37:35 Bastien Nocera wrote: > > On Wed, 2017-01-04 at 09:43 +0200, Ivaylo Dimitrov wrote: > > > > > > On 3.01.2017 13:21, Bastien Nocera wrote: > > > > On Mon, 2017-01-02 at 18:09 +0100, Pali Rohár wrote: > > > > > On Monday 02 January 2017 16:27:05 Bastien Nocera wrote: > > > > > > On Sun, 2016-12-25 at 11:04 +0100, Pali Rohár wrote: > > > > > > > This patch allows user to disable events from any input > > > > > > > device so > > > > > > > events > > > > > > > would not be delivered to userspace. > > > > > > > > > > > > > > Currently there is no way to disable particular input device > > > > > > > by > > > > > > > kernel. > > > > > > > User for different reasons would need it for integrated PS/2 > > > > > > > keyboard or > > > > > > > touchpad in notebook or touchscreen on mobile device to > > > > > > > prevent > > > > > > > sending > > > > > > > events. E.g. mobile phone in pocket or broken integrated PS/2 > > > > > > > keyboard. > > > > > > > > > > > > > > This is just a RFC patch, not tested yet. Original post about > > > > > > > motivation > > > > > > > about this patch is there: https://lkml.org/lkml/2014/11/29/9 > > > > > > > 2 > > > > > > > > > > > > Having implemented something of that ilk in user-space (we > > > > > > automatically disable touch devices when the associated screen > > > > > > is > > > > > > turned off/suspended), I think this might need more thought. > > > > > > > > > > How to implement such thing in userspace? I think you cannot do > > > > > that > > > > > without rewriting every one userspace application which uses > > > > > input. > > > > > > > > > > > What happens when a device is opened and the device disabled > > > > > > > > > > through > > > > > > sysfs, are the users revoked? > > > > > > > > > > Applications will not receive events. Same as if input device > > > > > does > > > > > not > > > > > generates events. > > > > > > > > > > > Does this put the device in suspend in the same way that > > > > > > closing > > > > > > > > > > the > > > > > > device's last user does? > > > > > > > > > > Current code not (this is just RFC prototype), but it should be > > > > > possible > > > > > to implement. > > > > > > > > > > > Is this not better implemented in user-space at the session > > > > > > level, > > > > > > where it knows about which output corresponds to which input > > > > > > > > > > device? > > > > > > > > > > How to do that without rewriting existing applications? > > > > > > > > > > > Is this useful enough to disable misbehaving devices on > > > > > > hardware, > > > > > > > > > > so > > > > > > that the device is not effective on boot? > > > > > > > > > > In case integrated device is absolutely unusable and generates > > > > > always > > > > > random events, it does not solve problem at boot time. > > > > > > > > > > But more real case is laptop with closed LID press buttons and > > > > > here > > > > > it > > > > > is useful. > > > > > > > > There's usually a display manager in between the application and > > > > the > > > > input device. Whether it's X.org, or a Wayland compositor. Even > > > > David's > > > > https://github.com/dvdhrm/kmscon could help for console > > > > applications. > > > > > > > > > > I think the use cases are not clearly explained, will try to: > > > > > > 1. Imagine you have a mobile phone, with a touchscreen, a slide > > > keyboard, a keyboard-slide sensor, a proximity sensor and a couple of > > > GPIOs, set-up as gpio keys. And you want to carry that phone in your > > > pocket, without being worried that it will pick-up an incoming call by > > > itself while in the pocket, so: > > > > > > - slide keyboard is closed, you "lock" the phone before put it in your > > > pocket - in that state, touchscreen and most of the gpio-keys should be > > > "disabled", so no touches are registered waking-up the device without > > > need. > > > - a call comes, proximity gets "enabled", but TS should stay disabled as > > > proximity detects "the phone is in a pocket" > > > - you get your phone out of your pocket - proximity detects no more > > > obstacles, so now TS has to be enabled giving you a chance to pick up > > > the incoming call. > > > > > > "disabling" of gpio-keys is clear, but how to make TS and proximity > > > inactive when needed? Sure, touches can be simply ignored (by using > > > xinput "Device Enabled" 0 on x11), same for proximity, but keep in mind > > > this is a battery-operated device, so we don't want CPU wake-ups with no > > > need. > > > > I'm pretty certain that the libinput or evdev Xorg drivers would close > > the underlying device so that it can go into power save. > > When they close evdev device? At least I need to explicitly call xinput. yeah, because setting that property is the way to tell X that we don't need to listen for events on that device. so we close the fd. libinput has the "send even
Re: [PATCH v4 0/4] Make input drivers y2038 safe
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 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 >
Re: [PATCH v2 2/2] HID: input: do not increment usages when a duplicate is found
On Fri, Dec 08, 2017 at 03:28:18PM +0100, Benjamin Tissoires wrote:
> This is something that bothered us from a long time. When hid-input
> doesn't know how to map a usage, it uses *_MISC. But there is something
> else which increments the usage if the evdev code is already used.
>
> This leads to few issues:
> - some devices may have their ABS_X mapped to ABS_Y if they export a bad
> set of usages (see the DragonRise joysticks IIRC -> fixed in a specific
> HID driver)
> - *_MISC + N might (will) conflict with other defined axes (my Logitech
> H800 exports some multitouch axes because of that)
> - this prevents to freely add some new evdev usages, because "hey, my
> headset will now report ABS_COFFEE, and it's not coffee capable".
>
> So let's try to kill this nonsense, and hope we won't break too many
> devices.
>
> I my headset case, the ABS_MISC axes are created because of some
> proprietary usages, so we might not break that many devices.
>
> For backward compatibility, a quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE
> is created and can be applied to any device that needs this behavior.
>
> Signed-off-by: Benjamin Tissoires
Acked-by: Peter Hutterer
Cheers,
Peter
> ---
>
> changes in v2:
> - fixed a bug where the flag was not used properly and prevented to
> remove devices
> - downgrade the error message from info to debug, given that when
> hid-generic binds first, it will output such kernel log for every
> multitouch device.
>
> drivers/hid/hid-input.c | 33 +++--
> include/linux/hid.h | 2 ++
> 2 files changed, 33 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index 04d01b57d94c..31bbeb7019bd 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -1100,8 +1100,31 @@ static void hidinput_configure_usage(struct hid_input
> *hidinput, struct hid_fiel
>
> set_bit(usage->type, input->evbit);
>
> - while (usage->code <= max && test_and_set_bit(usage->code, bit))
> - usage->code = find_next_zero_bit(bit, max + 1, usage->code);
> + /*
> + * This part is *really* controversial:
> + * - HID aims at being generic so we should do our best to export
> + * all incoming events
> + * - HID describes what events are, so there is no reason for ABS_X
> + * to be mapped to ABS_Y
> + * - HID is using *_MISC+N as a default value, but nothing prevents
> + * *_MISC+N to overwrite a legitimate even, which confuses userspace
> + * (for instance ABS_MISC + 7 is ABS_MT_SLOT, which has a different
> + * processing)
> + *
> + * If devices still want to use this (at their own risk), they will
> + * have to use the quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE, but
> + * the default should be a reliable mapping.
> + */
> + while (usage->code <= max && test_and_set_bit(usage->code, bit)) {
> + if (device->quirks & HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE) {
> + usage->code = find_next_zero_bit(bit,
> + max + 1,
> + usage->code);
> + } else {
> + device->status |= HID_STAT_DUP_DETECTED;
> + goto ignore;
> + }
> + }
>
> if (usage->code > max)
> goto ignore;
> @@ -1610,6 +1633,8 @@ int hidinput_connect(struct hid_device *hid, unsigned
> int force)
> INIT_LIST_HEAD(&hid->inputs);
> INIT_WORK(&hid->led_work, hidinput_led_worker);
>
> + hid->status &= ~HID_STAT_DUP_DETECTED;
> +
> if (!force) {
> for (i = 0; i < hid->maxcollection; i++) {
> struct hid_collection *col = &hid->collection[i];
> @@ -1676,6 +1701,10 @@ int hidinput_connect(struct hid_device *hid, unsigned
> int force)
> goto out_unwind;
> }
>
> + if (hid->status & HID_STAT_DUP_DETECTED)
> + hid_dbg(hid,
> + "Some usages could not be mapped, please use
> HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE if this is legitimate.\n");
> +
> return 0;
>
> out_unwind:
> diff --git a/include/linux/hid.h b/include/linux/hid.h
> index 421b62b77c69..de3a8700ccf1 100644
> --- a/include/linux/hid.h
> +++ b/include/linux/hid.h
> @@ -344,6 +344,7 @@ struct hid_item {
> #define HID_QUIRK_SKIP_OUTPUT_REPORT_ID 0x0002
> #def
[PATCH] asus-wireless: send an EV_SYN/SYN_REPORT between state changes
Sending the switch state change twice within the same frame is invalid evdev protocol and only works if the client handles keys immediately as well. Processing events immediately is incorrect, it forces a fake order of events that does not exist on the device. Recent versions of libinput changed to only process the device state and SYN_REPORT time, so now the key event is lost. https://bugs.freedesktop.org/show_bug.cgi?id=104041 Signed-off-by: Peter Hutterer --- drivers/platform/x86/asus-wireless.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/platform/x86/asus-wireless.c b/drivers/platform/x86/asus-wireless.c index f3796164329e..d4aeac3477f5 100644 --- a/drivers/platform/x86/asus-wireless.c +++ b/drivers/platform/x86/asus-wireless.c @@ -118,6 +118,7 @@ static void asus_wireless_notify(struct acpi_device *adev, u32 event) return; } input_report_key(data->idev, KEY_RFKILL, 1); + input_sync(data->idev); input_report_key(data->idev, KEY_RFKILL, 0); input_sync(data->idev); } -- 2.13.6
Re: [PATCH] HID: input: enable Totem on the Dell Canvas 27
On Wed, Nov 15, 2017 at 02:42:40PM +, mario.limoncie...@dell.com wrote: > > -Original Message- > > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] > > Sent: Wednesday, November 15, 2017 6:53 AM > > To: Dmitry Torokhov > > Cc: Peter Hutterer ; Jiri Kosina > > ; > > Limonciello, Mario ; > > linux-in...@vger.kernel.org; > > linux-kernel@vger.kernel.org > > Subject: Re: [PATCH] HID: input: enable Totem on the Dell Canvas 27 > > > > On Nov 14 2017 or thereabouts, Dmitry Torokhov wrote: > > > On Tue, Nov 14, 2017 at 06:50:43PM +1000, Peter Hutterer wrote: > > > > sorry, this one got stuck in my outbox. > > > > > > > > On Fri, Nov 10, 2017 at 11:26:35AM +0100, Benjamin Tissoires wrote: > > > > > The Dell Canvas 27 has a tool that can be put on the surface and acts > > > > > as a dial. The firmware processes the detection of the tool and > > > > > forward > > > > > regular HID reports with X, Y, Azimuth, rotation, width/height. > > > > > > > > > > The firmware also exports Contact ID, Countact Count which may hint > > > > > that > > > > > several totems can be used at the same time, but for now, only allow > > > > > one totem at a time. > > > > > > > > > > We also ignore scan time in hid-input.c because there is not much > > > > > point > > > > > to forward it now given that the indication of the tool being present > > > > > is already provided through BTN_TOOL_DIAL. > > > > > > > > > > We need to add a new BTN_TOOL_DIAL event because the HID mapping > > > > > suggests that this tool is aimed at being used by the system and not > > > > > the applications. Also this prevents current systemd heuristics to > > > > > apply ID_INPUT_TOUCHSCREEN to this new type of devices. > > > > > > > > > > I mapped Azimuth to ABS_WHEEL to somehow ressemble the Wacom Pads. > > > > > > > > HID docs indicate this is a full tool rotation, so ABS_RZ would be more > > > > appropriate? > > > > > > > > "Azimuth > > > > The counter-clockwise rotation of the cursor about the Z-axis." > > > > > > Right. We night also want to consider whether we need to convert HID to > > > Linux values, as HID is counter-clockwise, and I suspect Linux will be > > > clockwise (what do we report for joysticks?), similar to what we had for > > > ABS_MT_ORIENTATION. > > > > > > > > > > > But you also say it has rotation, so this is a bit confusing now :) > > > > We should also use INPUT_PROP_DIRECT here. > > > > > > > > > Last, both Width and Heigth are groupped together, the FW reports > > > > > > > > typo: grouped > > > > > > > > > similar values for both and we are out of ABS_* events. > > > > > > > > > > Link: https://bugzilla.redhat.com/show_bug.cgi?id=1511846 > > > > > > > > > > Signed-off-by: Benjamin Tissoires > > > > > --- > > > > > > > > > > Hi, > > > > > > > > > > This is probably v4.16 material as we are close to the merge window > > > > > (I wouldn't mind it applied in v4.15 though ;-P) > > > > > > > > I'm going to be annoying here and say I'd like to figure out how to add > > > > this > > > > to libinput first to figure out what details can go wrong before we > > > > merge it > > > > and commit to this forever. Hopefully that shouldn't take that long... > > > > > > > > I had a chat with Peter this morning. TL;DR is I'll need to rework on > > this more heavily to provide the final version with MT axes, and skip > > the single device implementation. I have no ideas if the Dell Canvas > > can report more than one totem, but the report descriptor would say so, > > so we better have a proper implementation instead of having one for > > single device capable and one for multiple devices. > > The Canvas can only support one large totem at a time. that's the current version but I doubt this will remain so for the upcoming years. We can support one totem through the MT protocol but it'll be hard to support multiple totems through the single touch protocol. So better safe than sorry. Cheers, Peter > > I'l
Re: [PATCH] HID: input: enable Totem on the Dell Canvas 27
sorry, this one got stuck in my outbox.
On Fri, Nov 10, 2017 at 11:26:35AM +0100, Benjamin Tissoires wrote:
> The Dell Canvas 27 has a tool that can be put on the surface and acts
> as a dial. The firmware processes the detection of the tool and forward
> regular HID reports with X, Y, Azimuth, rotation, width/height.
>
> The firmware also exports Contact ID, Countact Count which may hint that
> several totems can be used at the same time, but for now, only allow
> one totem at a time.
>
> We also ignore scan time in hid-input.c because there is not much point
> to forward it now given that the indication of the tool being present
> is already provided through BTN_TOOL_DIAL.
>
> We need to add a new BTN_TOOL_DIAL event because the HID mapping
> suggests that this tool is aimed at being used by the system and not
> the applications. Also this prevents current systemd heuristics to
> apply ID_INPUT_TOUCHSCREEN to this new type of devices.
>
> I mapped Azimuth to ABS_WHEEL to somehow ressemble the Wacom Pads.
HID docs indicate this is a full tool rotation, so ABS_RZ would be more
appropriate?
"Azimuth
The counter-clockwise rotation of the cursor about the Z-axis."
But you also say it has rotation, so this is a bit confusing now :)
We should also use INPUT_PROP_DIRECT here.
> Last, both Width and Heigth are groupped together, the FW reports
typo: grouped
> similar values for both and we are out of ABS_* events.
>
> Link: https://bugzilla.redhat.com/show_bug.cgi?id=1511846
>
> Signed-off-by: Benjamin Tissoires
> ---
>
> Hi,
>
> This is probably v4.16 material as we are close to the merge window
> (I wouldn't mind it applied in v4.15 though ;-P)
I'm going to be annoying here and say I'd like to figure out how to add this
to libinput first to figure out what details can go wrong before we merge it
and commit to this forever. Hopefully that shouldn't take that long...
Cheers,
Peter
> The patch does the job but we probably need to decide if the mappings
> I chose are correct.
>
> For the record, I uploaded some evemu-record traces and hid-recorder
> traces in the RH Bz linked above to keep traces of them.
> The interesting one is the evemu one for the totem with this patch
> applied:
> https://bugzilla.redhat.com/attachment.cgi?id=1350389
>
> Cheers,
> Benjamin
>
> drivers/hid/hid-input.c| 28 +++-
> drivers/hid/hid-multitouch.c | 11 +++
> include/linux/hid.h| 6 ++
> include/uapi/linux/input-event-codes.h | 1 +
> 4 files changed, 45 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index 04d01b57d94c..7da72b571b7d 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -229,6 +229,7 @@ __s32 hidinput_calc_abs_res(const struct hid_field
> *field, __u16 code)
> case ABS_X:
> case ABS_Y:
> case ABS_Z:
> + case ABS_TOOL_WIDTH:
> case ABS_MT_POSITION_X:
> case ABS_MT_POSITION_Y:
> case ABS_MT_TOOL_X:
> @@ -786,13 +787,24 @@ static void hidinput_configure_usage(struct hid_input
> *hidinput, struct hid_fiel
> map_abs_clear(ABS_TILT_Y);
> break;
>
> + case 0x3f: /* Azimuth */
> + map_abs_clear(ABS_WHEEL);
> + break;
> +
> case 0x33: /* Touch */
> - case 0x42: /* TipSwitch */
> case 0x43: /* TipSwitch2 */
> device->quirks &= ~HID_QUIRK_NOTOUCH;
> map_key_clear(BTN_TOUCH);
> break;
>
> + case 0x42: /* TipSwitch */
> + if (field->application == HID_GD_SYSTEM_MULTIAXIS) {
> + map_key_clear(BTN_TOOL_DIAL);
> + } else {
> + device->quirks &= ~HID_QUIRK_NOTOUCH;
> + map_key_clear(BTN_TOUCH);
> + }
> + break;
> case 0x44: /* BarrelSwitch */
> map_key_clear(BTN_STYLUS);
> break;
> @@ -806,6 +818,20 @@ static void hidinput_configure_usage(struct hid_input
> *hidinput, struct hid_fiel
> map_key_clear(BTN_TOUCH);
> break;
>
> + case 0x48: /* WIDTH */
> + case 0x49: /* HEIGHT */
> + map_abs_clear(ABS_TOOL_WIDTH);
> + break;
> +
> + case 0x51: /* CONTACT ID */
> + goto ignore;
> +
> + case 0x54: /* CONTACT COUNT */
> + goto ignore;
> +
> + case 0x56: /* SCANTIME */
> + goto ignore;
> +
> case 0x46: /* TabletPick */
> case 0x5a: /* SecondaryBarrelSwitch */
> map_key_clear(BTN_STYLUS2);
> diff --git a/drivers/hid/hid-multitouch.c
Re: [RFC] HID: input: do not increment usages when a duplicate is found
A bit late, but this has bitten us again recently. below are two
typos/nitpicks comments
On Mon, Jun 19, 2017 at 11:55:13AM +0200, Benjamin Tissoires wrote:
> This is something that bothered us from a long time. When hid-input
'for a long time'
> doesn't know how to map a usage, it uses *_MISC. But there is something
> else which increments the usage if the evdev code is already used.
this sentence is a bit confusing, needs to be reworded.
Acked-by: Peter Hutterer
Cheers,
Peter
> This leads to few issues:
> - some devices may have their ABS_X mapped to ABS_Y if they export a bad
> set of usages (see the DragonRise joysticks IIRC -> fixed in a specific
> HID driver)
> - *_MISC + N might (will) conflict with other defined axes (my Logitech
> H800 exports some multitouch axes because of that)
> - this prevents to freely add some new evdev usages, because "hey, my
> headset will now report ABS_COFFEE, and it's not coffee capable".
>
> So let's try to kill this nonsense, and hope we won't break too many
> devices.
>
> I my headset case, the ABS_MISC axes are created because of some
> proprietary usages, so we might not break that many devices.
>
> For backward compatibility, a quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE
> is created and can be applied to any device that needs this behavior.
>
> Signed-off-by: Benjamin Tissoires
> ---
>
> Hi,
>
> well, given I'd like to have a formal "go" before spending too much time
> in this, I am sending this a an RFC.
> This won't solve all the user space problems (especially the detection of
> non-mt devices based on ABS_MT_SLOT - 1 being set), but it should help us
> extending the other event types.
>
> Jiri, this patch applies on top of for-next + my series that creates
> HID_QUIRK_HAVE_SPECIAL_DRIVER, so do not expect it to apply cleanly on your
> tree :)
>
> Cheers,
> Benjamin
>
> drivers/hid/hid-input.c | 33 +++--
> include/linux/hid.h | 2 ++
> 2 files changed, 33 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index ccdff1e..9a9be89 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -1025,8 +1025,31 @@ static void hidinput_configure_usage(struct hid_input
> *hidinput, struct hid_fiel
>
> set_bit(usage->type, input->evbit);
>
> - while (usage->code <= max && test_and_set_bit(usage->code, bit))
> - usage->code = find_next_zero_bit(bit, max + 1, usage->code);
> + /*
> + * This part is *really* controversial:
> + * - HID aims at being generic so we should do our best to export
> + * all incoming events
> + * - HID describes what events are, so there is no reason for ABS_X
> + * to be mapped to ABS_Y
> + * - HID is using *_MISC+N as a default value, but nothing prevents
> + * *_MISC+N to overwrite a legitimate even, which confuses userspace
> + * (for instance ABS_MISC + 7 is ABS_MT_SLOT, which has a different
> + * processing)
> + *
> + * If devices still want to use this (at their own risk), they will
> + * have to use the quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE, but
> + * the default should be a reliable mapping.
> + */
> + while (usage->code <= max && test_and_set_bit(usage->code, bit)) {
> + if (device->quirks & HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE) {
> + usage->code = find_next_zero_bit(bit,
> + max + 1,
> + usage->code);
> + } else {
> + device->status |= HID_STAT_DUP_DETECTED;
> + goto ignore;
> + }
> + }
>
> if (usage->code > max)
> goto ignore;
> @@ -1527,6 +1550,8 @@ int hidinput_connect(struct hid_device *hid, unsigned
> int force)
> INIT_LIST_HEAD(&hid->inputs);
> INIT_WORK(&hid->led_work, hidinput_led_worker);
>
> + hid->status &= ~HID_STAT_DUP_DETECTED;
> +
> if (!force) {
> for (i = 0; i < hid->maxcollection; i++) {
> struct hid_collection *col = &hid->collection[i];
> @@ -1593,6 +1618,10 @@ int hidinput_connect(struct hid_device *hid, unsigned
> int force)
> goto out_unwind;
> }
>
> + if (hid->status & HID_STAT_DUP_DETECTED)
> + hid_info(hid,
> + "Some usages could not be mapped, plea
Re: [PATCH v4] HID: hid-multitouch: support fine-grain orientation reporting
On Wed, Oct 11, 2017 at 10:43:24PM +0200, Henrik Rydberg wrote: > > > > , but I'd go for fixing the documentation. And re-reading it, it's not > > > > clear that the doc tells us to have [0,90]. It mentions negative values > > > > and out of ranges too, so we might just as well simply clarify that we > > > > rather have [-90,90], with 0 being "north". > > > > > > ... I'd like the documentation fix to go in together in one go with this > > > patch if possible. > > > > > > > Sounds like a plan. > > How about this patch? > > Henrik > > --- > > From b14f92066dfab3f8a255ec7b5a30cb1a864dc62f Mon Sep 17 00:00:00 2001 > From: Henrik Rydberg > Date: Wed, 11 Oct 2017 22:41:39 +0200 > Subject: [PATCH] Input: docs - clarify the usage of ABS_MT_ORIENTATION > > As more drivers start to support touch orientation, clarify how the > value range should be set to match the expected behavior in > userland. > > Signed-off-by: Henrik Rydberg > --- > Documentation/input/multi-touch-protocol.rst | 14 -- > 1 file changed, 8 insertions(+), 6 deletions(-) > > diff --git a/Documentation/input/multi-touch-protocol.rst > b/Documentation/input/multi-touch-protocol.rst > index 8035868..a0c5c03 100644 > --- a/Documentation/input/multi-touch-protocol.rst > +++ b/Documentation/input/multi-touch-protocol.rst > @@ -269,15 +269,17 @@ ABS_MT_ORIENTATION > The orientation of the touching ellipse. The value should describe a > signed > quarter of a revolution clockwise around the touch center. The signed > value > range is arbitrary, but zero should be returned for an ellipse aligned > with > -the Y axis of the surface, a negative value when the ellipse is turned to > -the left, and a positive value when the ellipse is turned to the > -right. When completely aligned with the X axis, the range max should be > -returned. > +the Y axis of the surface (north). A negative value should be returned > when > +the ellipse is turned to the left (west), this bit is good. > +with the smallest value reported > +when aligned with the negative X axis. The largest value should be > returned > +when aligned with the positive X axis. this bit is less precise than before, because 'smallest' doesn't mean 'minimum' but smallest value. so a device announcing -90,90 could think that returning -120 is a good idea for X alignment. I liked the previous "When completely aligned with the X axis, the range max should be returned.", it was less ambiguous. replacing 'smallest value'/'largest value' with -range_max/range_max should be sufficient here. > + > +The value range should be specified as [-range_max, range_max]. I'd really like this to be [0, max] == can only detect one quarter/half and [-max, +max] == can detect both directions. It's one extra bit of information that may come in useful at some point. > Touch ellipsis are symmetrical by default. For devices capable of true > 360 > -degree orientation, the reported orientation must exceed the range max to > +degree orientation, the reported orientation will exceed range_max, in > order to > indicate more than a quarter of a revolution. For an upside-down finger, > -range max * 2 should be returned. > ++- 2 * range_max should be returned. ack to this bit Cheers, Peter > > Orientation can be omitted if the touch area is circular, or if the > information is not available in the kernel driver. Partial orientation > -- > 2.14.1 >
Re: [PATCH 1/2] HID: multitouch: report MT_TOOL_PALM for non-confident touches
sorry, was at a conference/travelling and I'm slowly catching up. On Fri, Aug 11, 2017 at 10:29:07AM +0200, Henrik Rydberg wrote: > Hi Dmitry, > > > The meaning of confidence is literally "contact is too large to be a > > finger", so it is not touch state, but really tool identity. We do > > allow tool identity to change over time. > What I am arguing is rather that since "palm" is a property, just like > contact size, there should be no need to confuse that property with the > touch state, which is, as you state, what happens in userland when the tool > type is modified. Using a different event for the palm property ought to > remove that confusion. whether it's a property or a tool type is up for interpretation, imo neither is right or wrong. It's common enough that the tool type changes after touch down but it's equally common for the tool type to be set at start. > > The additional state is simply because we have never updated the tool > > type on release events and userspace is not expecting it and is likely > > to ignore any data in the slot that is accompanied with > > ABS_TRACKING_ID == -1. So we synthesize an extra event to have > > distinct tool change and release. > > We update all other properties of a contact freely at release, so > logically there is no good reason to treat palm, the binary version of max > contact size, differently. note that palm does not indicate max contact size, it's merely a magic property at which point the contact is not considered a normal finger anymore. It may be size related, but it's certainly doesn't imply that it's the maximum touch size and I expect this to be even less true of devices in the future. > > Mostly because with BTN_TOOL_PALM we are not able to decide which > > contact is turning into palm. Also, other drivers (RMI) use > > MT_TOOL_PALM and I would like to report palm state in unified way. > Precedent certainly matters, but in this case, I think the modification > promises problems down the road. I would rather suggest to add a new binary > palm property, with the precise meaning "contact size = max contact size", > and take it from there. I dont mind writing a patch for it if you agree. the closest interpretation would be "contact size/shape/location indicates that it is not a finger". I don't think you can easily narrow this down further, mostly because it's often driven by the firmware and who knows what that does. I can live with an extra property as well as long as it's per-touch, but I don't have any problems with MT_TOOL_PALM. Cheers, Peter
Re: [PATCH] Revert "HID: magicmouse: Set multi-touch keybits for Magic Mouse"
On Thu, Jun 15, 2017 at 01:35:50PM +0100, Daniel Stone wrote:
> Setting these bits causes libinput to fail to initialize the device;
> setting BTN_TOUCH and BTN_TOOL_FINGER causes it to treat the mouse as a
> touchpad, and it then refuses to continue when it discovers ABS_X is not
> set.
What happens if you set ID_INPUT_MOUSE and unset ID_INPUT_TOUCHPAD with a
udev rule/hwdb entry? I think it should work then although we'll ignore the
touch bits - that mouse would require some special handling in libinput to
expose all its features.
Cheers,
Peter
>
> This breaks all known Wayland compositors, as well as Xorg when the
> libinput driver is being used.
>
> This reverts commit f4b65b9563216b3e01a5cc844c3ba68901d9b195.
>
> Signed-off-by: Daniel Stone
> Cc: Che-Liang Chiou
> Cc: Thierry Escande
> Cc: Jiri Kosina
> Cc: Benjamin Tissoires
> ---
> drivers/hid/hid-magicmouse.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> Jiri, can you please get this into 4.12 final?
>
> diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c
> index 1d6c997b3001..20b40ad26325 100644
> --- a/drivers/hid/hid-magicmouse.c
> +++ b/drivers/hid/hid-magicmouse.c
> @@ -349,7 +349,6 @@ static int magicmouse_raw_event(struct hid_device *hdev,
>
> if (input->id.product == USB_DEVICE_ID_APPLE_MAGICMOUSE) {
> magicmouse_emit_buttons(msc, clicks & 3);
> - input_mt_report_pointer_emulation(input, true);
> input_report_rel(input, REL_X, x);
> input_report_rel(input, REL_Y, y);
> } else { /* USB_DEVICE_ID_APPLE_MAGICTRACKPAD */
> @@ -389,16 +388,16 @@ static int magicmouse_setup_input(struct input_dev
> *input, struct hid_device *hd
> __clear_bit(BTN_RIGHT, input->keybit);
> __clear_bit(BTN_MIDDLE, input->keybit);
> __set_bit(BTN_MOUSE, input->keybit);
> + __set_bit(BTN_TOOL_FINGER, input->keybit);
> + __set_bit(BTN_TOOL_DOUBLETAP, input->keybit);
> + __set_bit(BTN_TOOL_TRIPLETAP, input->keybit);
> + __set_bit(BTN_TOOL_QUADTAP, input->keybit);
> + __set_bit(BTN_TOOL_QUINTTAP, input->keybit);
> + __set_bit(BTN_TOUCH, input->keybit);
> + __set_bit(INPUT_PROP_POINTER, input->propbit);
> __set_bit(INPUT_PROP_BUTTONPAD, input->propbit);
> }
>
> - __set_bit(BTN_TOOL_FINGER, input->keybit);
> - __set_bit(BTN_TOOL_DOUBLETAP, input->keybit);
> - __set_bit(BTN_TOOL_TRIPLETAP, input->keybit);
> - __set_bit(BTN_TOOL_QUADTAP, input->keybit);
> - __set_bit(BTN_TOOL_QUINTTAP, input->keybit);
> - __set_bit(BTN_TOUCH, input->keybit);
> - __set_bit(INPUT_PROP_POINTER, input->propbit);
>
> __set_bit(EV_ABS, input->evbit);
>
> --
> 2.11.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI
On Thu, Jun 15, 2017 at 07:33:58AM +, Zheng, Lv wrote: > Hi, Peter > > > From: Peter Hutterer [mailto:peter.hutte...@who-t.net] > > Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID > > switch exported by ACPI > > > > On Thu, Jun 15, 2017 at 02:52:57AM +, Zheng, Lv wrote: > > > Hi, Benjamin > > > > > > > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] > > > > Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID > > > > switch exported by ACPI > > > > > > > > Hi, > > > > > > > > [Sorry for the delay, I have been sidetracked from this] > > > > > > > > On Jun 07 2017 or thereabouts, Lennart Poettering wrote: > > > > > On Thu, 01.06.17 20:46, Benjamin Tissoires > > > > > (benjamin.tissoi...@redhat.com) wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > Sending this as a WIP as it still need a few changes, but it mostly > > > > > > works as > > > > > > expected (still not fully compliant yet). > > > > > > > > > > > > So this is based on Lennart's comment in [1]: if the LID state is > > > > > > not reliable, > > > > > > the kernel should not export the LID switch device as long as we > > > > > > are not sure > > > > > > about its state. > > > > > > > > > > Ah nice! I (obviously) like this approach. > > > > > > > > Heh. Now I just need to convince Lv that it's the right approach. > > > > > > I feel we don't have big conflicts. > > > And I already took part of your idea into this patchset: > > > https://patchwork.kernel.org/patch/9771121/ > > > https://patchwork.kernel.org/patch/9771119/ > > > I tested my surface pros with Ubuntu, they are working as expected. > > > > > > > > > Note that systemd currently doesn't sync the state when the input > > > > > > node just > > > > > > appears. This is a systemd bug, and it should not be handled by the > > > > > > kernel > > > > > > community. > > > > > > > > > > Uh if this is borked, we should indeed fix this in systemd. Is there > > > > > already a systemd github bug about this? If not, please create one, > > > > > and we'll look into it! > > > > > > > > I don't think there is. I haven't raised it yet because I am not so sure > > > > this will not break again those worthless unreliable LID, and if we play > > > > whack a mole between the kernel and user space, things are going to be > > > > nasty. So I'd rather have this fixed in systemd along with the > > > > unreliable LID switch knowledge, so we are sure that the kernel behaves > > > > the way we expect it to be. > > > > > > This is my feeling: > > > We needn't go that far. > > > We can interpret "input node appears" into "default input node state". > > > > Sorry, can you clarify this bit please? I'm not sure what you mean here. > > Note that there's an unknown amount of time between "device node appearing > > in the system" and when a userspace process actually opens it and looks at > > its state. By then, the node may have changed state again. > > We can see: > "logind" has already implemented a timeout, and will not respond lid state > unless it can be stable within this timeout period. > I'm not an expert of logind, maybe this is because of "HoldOffTimeoutSec"? > > I feel "removing the input node for a period where its state is not trustful" > is technically identical to this mechanism. but you'd be making kernel policy based on one userspace implementation. e.g. libinput doesn't have a timeout period, it assumes the state is correct when an input node is present. Cheers, Peter
Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI
On Thu, Jun 15, 2017 at 02:52:57AM +, Zheng, Lv wrote: > Hi, Benjamin > > > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] > > Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID > > switch exported by ACPI > > > > Hi, > > > > [Sorry for the delay, I have been sidetracked from this] > > > > On Jun 07 2017 or thereabouts, Lennart Poettering wrote: > > > On Thu, 01.06.17 20:46, Benjamin Tissoires > > > (benjamin.tissoi...@redhat.com) wrote: > > > > > > > Hi, > > > > > > > > Sending this as a WIP as it still need a few changes, but it mostly > > > > works as > > > > expected (still not fully compliant yet). > > > > > > > > So this is based on Lennart's comment in [1]: if the LID state is not > > > > reliable, > > > > the kernel should not export the LID switch device as long as we are > > > > not sure > > > > about its state. > > > > > > Ah nice! I (obviously) like this approach. > > > > Heh. Now I just need to convince Lv that it's the right approach. > > I feel we don't have big conflicts. > And I already took part of your idea into this patchset: > https://patchwork.kernel.org/patch/9771121/ > https://patchwork.kernel.org/patch/9771119/ > I tested my surface pros with Ubuntu, they are working as expected. > > > > > Note that systemd currently doesn't sync the state when the input node > > > > just > > > > appears. This is a systemd bug, and it should not be handled by the > > > > kernel > > > > community. > > > > > > Uh if this is borked, we should indeed fix this in systemd. Is there > > > already a systemd github bug about this? If not, please create one, > > > and we'll look into it! > > > > I don't think there is. I haven't raised it yet because I am not so sure > > this will not break again those worthless unreliable LID, and if we play > > whack a mole between the kernel and user space, things are going to be > > nasty. So I'd rather have this fixed in systemd along with the > > unreliable LID switch knowledge, so we are sure that the kernel behaves > > the way we expect it to be. > > This is my feeling: > We needn't go that far. > We can interpret "input node appears" into "default input node state". Sorry, can you clarify this bit please? I'm not sure what you mean here. Note that there's an unknown amount of time between "device node appearing in the system" and when a userspace process actually opens it and looks at its state. By then, the node may have changed state again. Cheers, Peter > That's what you want for acpi button driver - we now defaults to "method" > mode. > > What's your opinion? > > Thanks > Lv >
Re: [PATCH] macintosh: move mac_hid driver to input/mouse.
On Fri, Jun 09, 2017 at 01:39:53PM +0200, Michal Suchánek wrote: > On Thu, 8 Jun 2017 16:18:28 -0700 > Dmitry Torokhov wrote: > > > On Thu, Jun 8, 2017 at 4:07 PM, Peter Hutterer > > wrote: > > > On Thu, Jun 08, 2017 at 03:18:42PM +0200, Michal Suchánek wrote: > > >> This is what evtest reports about my keyboard: > > >> > > >> Select the device event number [0-12]: 2 > > >> Input driver version is 1.0.1 > > >> Input device ID: bus 0x3 vendor 0x413c product 0x2107 version 0x111 > > >> Input device name: "DELL Dell USB Entry Keyboard" > > >> Supported events: > > >> Event type 0 (EV_SYN) > > >> Event type 1 (EV_KEY) > > >> Event code 1 (KEY_ESC) > > >> Event code 2 (KEY_1) > > >> Event code 3 (KEY_2) > > >> Event code 4 (KEY_3) > > >> ... > > >> Event code 193 (KEY_F23) > > >> Event code 194 (KEY_F24) > > >> Event code 240 (KEY_UNKNOWN) > > >> Event code 272 (BTN_LEFT) > > >> Event code 273 (BTN_RIGHT) > > >> Event code 274 (BTN_MIDDLE) > > >> Event type 4 (EV_MSC) > > >> Event code 4 (MSC_SCAN) > > >> Event type 17 (EV_LED) > > >> Event code 0 (LED_NUML) state 1 > > >> Event code 1 (LED_CAPSL) state 0 > > >> Event code 2 (LED_SCROLLL) state 0 > > >> Event code 3 (LED_COMPOSE) state 0 > > >> Event code 4 (LED_KANA) state 0 > > >> Key repeat handling: > > >> Repeat type 20 (EV_REP) > > >> Repeat code 0 (REP_DELAY) > > >> Value250 > > >> Repeat code 1 (REP_PERIOD) > > >> Value 33 > > >> Properties: > > > > > > looks like it's not tagged as ID_INPUT_MOUSE by the default udev > > > rules because for that we need x/y axes (either relative for real > > > mice or absolute ones for the VMWare USB mouse). This keyboard only > > > has buttons though. So it gets ID_INPUT_KEYBOARD for the keys, but > > > no ID_INPUT_MOUSE. > > > > > > Google isn't overly forthcoming on "DELL Dell USB Entry Keyboard" > > > but the few pictures I can find all point to a keyboard that > > > doesn't have any physical mouse buttons at all. Does yours have > > > buttons? Can you post a picture of it somewhere? > > > > > > > Michal is using udev/hwdb to replace some of the keys on his keyboard > > to generate BTN_RIGHT/BTN_MIDDLE trying to achive the same end result > > as with mac_hid. It is not the default keyboard behavior. Having > > another custom udev rule to mark the device as ID_INPUT_MOUSE is a > > fair requirement in this case I think. > > > > Which is done in different place, and uses device matching with > completely different patterns. So for this to work reasonably either > > - all devices should have all capabilities by default > - the capabilities should be detected based on the events actually >available on the device > > And if my keyboard actually claimed to have relative axis because of > some great firmware engineering on the manufacturer's part and I found > how to remove them in hwdb it would not take effect either. https://github.com/systemd/systemd/blob/master/rules/50-udev-default.rules.in calls input-id which sets the ID_INPUT_* tags. If you modify the capabilities after that happens, you need to call input-id again to get updated udev properties. There is no kernel facility to handle devices that change capabilities at runtime. We discussed this a short while ago (search for SYN_CONFIG) but it's ... tricky. Cheers, Peter
Re: [PATCH] macintosh: move mac_hid driver to input/mouse.
On Thu, Jun 08, 2017 at 03:18:42PM +0200, Michal Suchánek wrote: > This is what evtest reports about my keyboard: > > Select the device event number [0-12]: 2 > Input driver version is 1.0.1 > Input device ID: bus 0x3 vendor 0x413c product 0x2107 version 0x111 > Input device name: "DELL Dell USB Entry Keyboard" > Supported events: > Event type 0 (EV_SYN) > Event type 1 (EV_KEY) > Event code 1 (KEY_ESC) > Event code 2 (KEY_1) > Event code 3 (KEY_2) > Event code 4 (KEY_3) > ... > Event code 193 (KEY_F23) > Event code 194 (KEY_F24) > Event code 240 (KEY_UNKNOWN) > Event code 272 (BTN_LEFT) > Event code 273 (BTN_RIGHT) > Event code 274 (BTN_MIDDLE) > Event type 4 (EV_MSC) > Event code 4 (MSC_SCAN) > Event type 17 (EV_LED) > Event code 0 (LED_NUML) state 1 > Event code 1 (LED_CAPSL) state 0 > Event code 2 (LED_SCROLLL) state 0 > Event code 3 (LED_COMPOSE) state 0 > Event code 4 (LED_KANA) state 0 > Key repeat handling: > Repeat type 20 (EV_REP) > Repeat code 0 (REP_DELAY) > Value250 > Repeat code 1 (REP_PERIOD) > Value 33 > Properties: looks like it's not tagged as ID_INPUT_MOUSE by the default udev rules because for that we need x/y axes (either relative for real mice or absolute ones for the VMWare USB mouse). This keyboard only has buttons though. So it gets ID_INPUT_KEYBOARD for the keys, but no ID_INPUT_MOUSE. Google isn't overly forthcoming on "DELL Dell USB Entry Keyboard" but the few pictures I can find all point to a keyboard that doesn't have any physical mouse buttons at all. Does yours have buttons? Can you post a picture of it somewhere? Cheers, Peter
Re: [PATCH] macintosh: move mac_hid driver to input/mouse.
On Wed, Jun 07, 2017 at 09:17:37PM +0200, Michal Suchánek wrote:
> On Wed, 7 Jun 2017 10:16:22 -0700
> Dmitry Torokhov wrote:
>
> > On Wed, Jun 07, 2017 at 06:53:51PM +0200, Michal Suchánek wrote:
> > > On Sun, 28 May 2017 10:55:40 -0700
> > > Dmitry Torokhov wrote:
> > >
> > > > On Sun, May 28, 2017 at 11:47:58AM +0200, Michal Suchanek wrote:
> > > > > On Tue, 9 May 2017 17:43:27 -0700
> > > > > Dmitry Torokhov wrote:
> > > > >
> > > > > > Hi Michal,
> > > > > >
> > > > > > On Tue, May 09, 2017 at 09:14:18PM +0200, Michal Suchanek
> > > > > > wrote:
> > > > > > > There is nothing mac-specific about this driver. Non-mac
> > > > > > > hardware with suboptimal built-in pointer devices exists.
> > > > > > >
> > > > > > > This makes it possible to use this emulation not only on x86
> > > > > > > and ppc notebooks but also on arm and mips.
> > > > > >
> > > > > > I'd rather we did not promote from drivers/macintosh to other
> > > > > > platforms, but rather removed it. The same functionality can
> > > > > > be done from userspace.
> > > > >
> > > > > What is the status of this?
> > > >
> > > > The same as in above paragraph.
> > > >
> > > > >
> > > > > Do you reply to every patch to drivers/input that is not the the
> > > > > core infrastructure that you would rather drop the driver
> > > > > because it can be done is in userspace?
> > > > >
> > > > > It sure can be done. Remove everything but the bus drivers and
> > > > > uinput from drivers/input and the rest can be done in userspace.
> > > > >
> > > > > The question is who does it?
> > > > >
> > > > > Are you saying that you will implement the userspace
> > > > > equivalent?
> > > >
> > > > No, I spend my time mostly with the kernel.
> > > >
> > > > >
> > > > > If not then please do your job as maintainer and accept trivial
> > > > > patches for perfectly working drivers we have now.
> > > >
> > > > I am doing my job as a maintainer right now. The driver might have
> > > > been beneficial 15 years ago, when we did not have better options,
> > > > but I would rather not continue expanding it's use.
> > > >
> > > > The main problem with the driver is that the functionality it is
> > > > not easily discoverable by end users. And once you plumb it
> > > > through userspace to present users with options you might as well
> > > > handle it all in userspace.
> > > >
> > > > >
> > > > > If you want to move drivers/input into userspace I am not
> > > > > against it but I am not willing to do that for you either.
> > > >
> > > > Then we are at impasse.
> > > >
> > > > >
> > > > > >
> > > > > > What hardware do you believe would benefit from this and
> > > > > > why?
> > > > >
> > > > > Any touchpad hardware where you cannot press two buttons at
> > > > > once to emulate the third button due to hardware design. And
> > > > > any touchpad hardware on which some of the buttons are broken
> > > > > when it comes to it.
> > > > >
> > > > > It is built into a notebook and works fine for moving the
> > > > > cursor but due to lack of usable buttons you still need a mouse
> > > > > to use the notebook.
> > > >
> > > > Have you tried simply redefining keymap of your keyboard to emit
> > > > BTN_RIGHT/BTN_MIDDLE? Both atkbd and HID keyboards support keymap
> > > > updates from userspace/udev/hwdb and if there is a driver that
> > > > does not support it I will take patches fixing that.
> > >
> > > Indeed, they do support it. Such keymap update just does not work as
> > > mouse button regardless of sending the BTN_* event. At least not in
> > > X11.
> > >
> > > So what is next?
> >
> > Teach X11 to handle it properly.
> >
> > Thanks.
> >
>
> That's actually libinputs fault. It marks devices with some random
> capabilities and when the event does not match capability set it is
> dropped.
just because it's not immediately apparent doesn't mean it's random.
We use ID_INPUT_* from udev to determine the device capabilities. In some
cases we override it when we have some information udev doesn't have. e.g.
we disable gestures on some touchpads known to be inaccurate for
multi-finger gestures. or on some devices we disable event codes because the
device doesn't actually have them. see my explanation here:
https://who-t.blogspot.com.au/2015/06/libinput-and-lack-of-device-types.html
the reason we do it this way is so that a) all of the stack can agree on a
device's device type and b) you can override many misdetections with a hwdb
entry or a custom udev rule rather than waiting for a new libinput release
that encodes the new magic.
> Adding the capability with /etc/udev/rules.d/xxx-input.rules
>
> ENV{ID_INPUT_KEYBOARD}=="1" ENV{ID_INPUT_MOUSE}="1"
>
> resolves the problem. It must come very late in rules otherwise
> something resets it back.
>
> This is inefficient to enable by default because libinput must create
> a second shadow X11 device for devices that generate both input and
>
Re: [WIP PATCH 2/4] ACPI: button: remove the LID input node when the state is unknown
On Tue, Jun 06, 2017 at 12:22:09PM +0200, Benjamin Tissoires wrote: [...] > > This is because the aml table puts many Notify(LID, 0x80) in various > > control methods. > > And not one of them but multiple of them will be invoked by various OS > > drivers during suspend/resume period. > > I think this is not an isolated platform that will invoke multiple > > redundant "Notify(lid)". > > > > Fortunately, the lid state for the multiple notify(lid) should be same as > > the first "Notify(lid)". > > I suppose this is why SW_LID is invented, as it can really filter such > > redundant events. > > And user space finally can only see 1 "close" event. > > > > But unconditionally prepending "open" before all "close" events surely can > > break the logic by > > delivering multiple "close" events to the user space. > > That doesn't matter. What matters is the state of the switch, not the > event. So if user space receives (in case we marked the switch as not > reliable) several close events, all user space will do is realize that > the state is still closed and will act accordingly. [...] > Again, we don't care if the "event" comes from ACPI, the driver itself or > user space (libinput). All that matters is the current state of the > input node switch, that needs to match the physical world at any time. as extra comment on those two: you cannot guarantee when e.g. libinput checks the state. it may start up after the kernel has updated the EV_SW state, it may close and re-open a device without notice (disabling a device in X has that effect for example). So the EV_SW/SW_LID events are nice to have, but we really rely on the *state* of the switch more than the events. Cheers, Peter
Re: [PATCH] macintosh: move mac_hid driver to input/mouse.
On Tue, May 30, 2017 at 02:56:18PM +0200, Michal Suchánek wrote: > > > > I concede userspace doesn't have the feature, but you should > > > > really have a look at libinput (i.e. open a bug on > > > > bugs.freedesktop.org) and request the feature here. > > > > > > > > > > > > > > > > > > > > > > And if it is not rejected by the kernel. > > > > > > > > > > > > It should not. setkeycodes definitely works on atkbd. > > > > > > > > > > > > > And if it does not > > > > > > > crash your X server which is very picky about receiving > > > > > > > pointer events from a keyboard or the other way > > > > > > > around. > > > > > > > > > > > > Sounds like you want to make X server more resilient ;) > > > > > > > > > > This is an inherent design flaw in the X server known for > > > > > years. It has separate keyboard and pointer devices and while > > > > > people are trying to patch it up occasionally a bug pops out > > > > > that crashes the Xserver when an event is received from > > > > > non-matching device type. fwiw, the pointer/keyboard split problem was fixed in xf86-input-libinput with 1f43f3921f6c in late 2015. it's possible to fix it in the same manner for the evdev driver, but someone would have to be very motivated. > > > > > > > > > > Once X server dies and is replaced be Y server or Z server or > > > > > whatever it will make life easier in so many ways. > > > > > > > > We already have libinput that tends to replace the Xorg input > > > > part (at least everything which is not protocol). > > > > > > And the protocol still has the split to pointer and keyboard. It is > > > technically possible to map mouse button presses with XKB but it > > > only works in X and is undocumented and really difficult to do. And > > > it does not work outside of X. > > > > I never talked about XKB. Libinput has a view on all input devices and > > can redirect whatever events it sees into any other input device. > > From a X perspective it's as if the emulated button would have been > > generated by the touchpad itself. > > > > > > > > > So if the feature is in > > > > libinput, it should be available in X.org directly, and you will > > > > be saved. > > > > > > Not everything uses libinput. So no, using libinput is not the > > > answer. > > > > If you do not want to upgrade and use the latest development tools, > > then sure, you can always use the mac_hid emulation. But we will not > > resurrect it because it's something from the past. > > > > > > > > Also libinput people suggest to use hwdb for mapping which is back > > > to where we were: > > > https://lists.freedesktop.org/archives/wayland-devel/2015-December/026223.html > > > Note: in this thread I specifically say that remapping for *broken* keys should go in the hwdb, anything else needs to go into userspace. > > Libinput people are basically Peter Hutterer alone. And in the > > keyboard layout mapping, yes users should use hwdb/systemd for that. > > In your precise case, libinput should have a setting that redirect > > the incoming key onto a button of a different device. It's not > > implemented, it's doable, but you won't receive a NACK as you get > > here, because you have a valid use case for it. > > Libinput is not the place either. Libinput is a library for using the > input subsystem, not the input subsystem. So while it might be > advisable to use it when you can there will always be applications that > do not use it and those should receive correct input as well. I'm gonna chime in here and say that emulating button events from keys + mouse events is (probably) not something I'd merge into libinput anyway. I'd like to see the touchpads that are unable to even detect two fingers first. I haven't seen one of those released in 8 years and the ones that are left are probably at the end of their lifecycle. [However, you'll be happy to know that with libiput 1.7 and 1.6.2 we added clickfinger support for the apple onebutton touchpads. And that was only January this year. Both users have been partying non-stop since, I suspect.] Almost all touchpads these days are clickpads, i.e. they only have a single (left) button and a
Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"
On May 25 2017, Benjamin Tissoires wrote: > On May 15 2017 or thereabouts, Rafael J. Wysocki wrote: > > >> >> Benjamin, my understanding is that this is the case, is it correct? > > >> > > > >> > That is correct. This patch I reverted introduces regression for > > >> > professional > > >> > laptops that expect the LID switch to be reported accurately. > > >> > > >> And from a user's perspective, what does not work any more? > > > > > > If you boot or resume your laptop with the lid closed on a docking > > > station while using an external monitor connected to it, both internal > > > and external displays will light on, while only the external should. > > > > > > There is a design choice in gdm to only provide the greater on the > > > internal display when lit on, so users only see a gray area on the > > > external monitor. Also, the cursor will not show up as it's by default > > > on the internal display too. > > > > > > To "fix" that, users have to open the laptop once and close it once > > > again to sync the state of the switch with the hardware state. > > > > OK > > > > Yeah, that sucks. > > > > So without the Lv's patch the behavior (on the systems in question) is > > as expected, right? > > Would you agree to take both these reverts without Lv's ACK? We already > tried to explain for 2 weeks that they are valuable, but it seems we > can't make change his mind. > > I have more that 26 emails in my INBOX (not counting my replies) and I > would really like switching to more valuable work than explaining again > and again that when a regression is introduced, it needs to be fixed (or > reverted in that case). Yes please. This should have stopped right after "regression on basically every decent laptop out there" and we should be discussing how to fix the devices that actually need quirks because they're broken. Instead it turned into a discussion on why we should stick with the regression and convince all of userspace to change and implement broken heuristics. I've used up my time budget for that. Cheers, Peter
RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"
Hi Lv > > Yes, it's called a quirk. And the good practice is to register those > > quirks and make them available to everybody. Being in hwdb in user space > > or in acpi/button in kernel space doesn't matter, we need them. > > I have no objections but concerns related to the combination of "default > mode" and "quirk responsibles". > From my point of view, these are my conclusions: > 1. If you want to use libinput to generate quirks, you should use "ignore" > rather than "method" mode as default mode; libinput does not replace the kernel. libinput can help with some heuristics, but that should be the exception, not the default. And heuristics cannot detect some cases, ignore suffers from that problem (see below). > 2. If you want to use button driver to generate quirks, we need "close" mode; > 3. If GDM can change or users are ok use command lines, we can remain to use > "open" as the default behavior. > (I'll send technical details in private about these conclusions) > But you seem to always: > 1. Say no to "ignore" which makes 1 impossible; as an outsider, 'ignore' makes me wonder: Why wouldn't you query the state of the hardware if it lets you? That's what we do in userspace with EV_SW. We don't just rely on the notification, we look at the state of it too. sure, some hardware is buggy and we can somehow work around this but that's not a reason to throw everyone else under the bus too. > 2. Say no to "close" which makes 2 impossible; 'close' forces userspace to fix up the kernel in every case rather than for those devices where method doesn't work correctly. That's just effectively deciding to be always the least wrong just to avoid a few outliers. (also, if the kernel is always wrong, what purpose does it serve? :) > 3. Say no to "open" which makes 3 impossible. as mentioned above, some things we cannot detect. we cannot detect a false-open with heuristics, this makes it impossible to fix with heuristics in userspace. for 'close' and 'method' we can take user input as indication that the lid isn't as closed as it pretends to be. That doesn't work the other way round, lack of user input does not imply the lid is closed. > > > We haven't asked user space to change. > > > We are just discussing the correctness of some user space behaviors. > > > > They *are* correct. > > They are following the exported ACPI documentation > > I doubt. In ACPI world, Windows is the only standard. ok, here I need to note something: ACPI doesn't matter to userspace. the kernel has EV_SW/SW_LID, which is *not* ACPI. that promises that a userspace can assume that if SW_LID is 1, then the lid is closed, otherwise it's open. Some leeway can be given because, well, reality, but a userspace behaviour to assume a lid is closed when the lid switch is set to that state should not be up for discussion. > > and the input node documentation. > > Quoting the input doc: > > file Documentation/input/event-codes.rst: > > EV_SW > > - > > > > EV_SW events describe stateful binary switches. For example, the SW_LID > > code is > > used to denote when a laptop lid is closed. > > > > Upon binding to a device or resuming from suspend, a driver must report > > the current switch state. This ensures that the device, kernel, and > > userspace > > state is in sync. > > > > Upon resume, if the switch state is the same as before suspend, then the > > input > > subsystem will filter out the duplicate switch state reports. The driver > > does > > not need to keep the state of the switch at any time. > > > > That's really a convenient feature for driver. > If I'm the driver writers, I would be very appreciated for being able to use > such features. > So you see I don't have objections to having this feature. > > I just have concerns related to: > 1. Is it required to have a timeout in systemd, forcing platform to suspend > again, just due to event delays? > 2. Is it required to use SW_LID to determine whether an internal display > should be lit on? > I don't see any conflicts between the ABI of EV_SW and the 2 questions. the ABI of EV_SW? that's just evdev. It seems you're discussing three, four things simultaneously, ACPI, the button driver, the evdev switch API and userspace behaviour in response to this whole thread. The simple answer is: the last bit doesn't matter - if EV_SW/SW_LID is on, the lid can be assumed to be closed. How you get to this point is your side of the problem :) And I'm willing to accommodate for some issues (see the heuristics benjamin already mentioned) but they should be exception, not the rule. but whether e.g. displays are lit or not has nothing to do with this discussion, it just doesn't matter what userspace does with the information. > > So no, you can't have 'ignore' or 'open' to be the default, because user > > space expects the switch to reflect the current state of the hardware. > > Then what's the benefit of having 'method' to be the default, > Given it is still not able to relia
Re: Synaptics RMI4 touchpad regression in 4.11-rc1
On Tue, Mar 28, 2017 at 06:50:44PM -0700, Andrew Duggan wrote: > On 03/19/2017 10:00 PM, Peter Hutterer wrote: > > On Fri, Mar 17, 2017 at 12:23:36PM -0700, Andrew Duggan wrote: > > > On 03/17/2017 09:57 AM, Benjamin Tissoires wrote: > > > > On Wed, Mar 15, 2017 at 2:19 AM, Andrew Duggan > > > > wrote: > > > > > On 03/13/2017 10:10 PM, Cameron Gutman wrote: > > > > > > On 03/13/2017 06:35 PM, Andrew Duggan wrote: > > > > > > > On 03/13/2017 06:15 AM, Benjamin Tissoires wrote: > > > > > > > > [Resending, forgot to add Jiri in CC] > > > > > > > > > > > > > > > > On Mar 13 2017 or thereabouts, Benjamin Tissoires wrote: > > > > > > > > > On Mar 13 2017 or thereabouts, Thorsten Leemhuis wrote: > > > > > > > > > > Lo! On 12.03.2017 02:55, Cameron Gutman wrote: > > > > > > > > > > > Beginning in 4.11-rc1, it looks like RMI4 is binding to > > > > > > > > > > > my XPS 13 > > > > > > > > > > > 9343's > > > > > > > > > > > Synaptics touchpad and dropping some errors into dmesg. > > > > > > > > > > > Here are the > > > > > > > > > > > messages that seem RMI-related: > > > > > > > > > > > > > > > > > > > > > > rmi4_f34 rmi4-00.fn34: rmi_f34v7_probe: Unrecognized > > > > > > > > > > > bootloader > > > > > > > > > > > version > > > > > > > > > > > rmi4_f34: probe of rmi4-00.fn34 failed with error -22 > > > > > > > > > > > rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: > > > > > > > > > > > Synaptics, > > > > > > > > > > > product: TM3038-001, fw id: 1832324 > > > > > > > > > > > input: Synaptics TM3038-001 as > > > > > > > > > > > /devices/pci:00/INT3433:00/i2c-7/i2c-DLL0665:01/0018:06CB:76AD.0001/input/input19 > > > > > > > > > > > hid-rmi 0018:06CB:76AD.0001: input,hidraw0: I2C HID v1.00 > > > > > > > > > > > Mouse > > > > > > > > > > > [DLL0665:01 06CB:76AD] on i2c-DLL0665:01 > > > > > > > > > > FWIW, I get this on my XPS 13 DE (9360) with 4.11-rc1: > > > > > > > > > > > > > > > > > > > > input: SynPS/2 Synaptics TouchPad as > > > > > > > > > > /devices/platform/i8042/serio1/input/input6 > > > > > > > > > > rmi4_f34 rmi4-00.fn34: rmi_f34v7_probe: Unrecognized > > > > > > > > > > bootloader > > > > > > > > > > version > > > > > > > > > > rmi4_f34: probe of rmi4-00.fn34 failed with error -22 > > > > > > > > > > rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: > > > > > > > > > > Synaptics, > > > > > > > > > > product: TM3038-003, fw id: 2375007 > > > > > > > > > > input: Synaptics TM3038-003 as > > > > > > > > > > > > > > > > > > > > /devices/pci:00/:00:15.1/i2c_designware.1/i2c-8/i2c-DLL075B:01/0018:06CB:76AF.0001/input/input20 > > > > > > > > > > hid-rmi 0018:06CB:76AF.0001: input,hidraw0: I2C HID v1.00 > > > > > > > > > > Mouse > > > > > > > > > > [DLL075B:01 06CB:76AF] on i2c-DLL075B:01 > > > > > > > > > > > > > > > > > > > > > […] > > > > > > > > > > > Compared to hid-multitouch, the RMI stack seems to have > > > > > > > > > > > completely > > > > > > > > > > > broken > > > > > > > > > > > palm rejection and introduced some random jumpiness > > > > > > > > > > > during fine > > > > > > > > > > > pointing > > > > > > > > > > > motions. I don't know if these issues are caused by the > > > > > > > > > > > above errors > > > > > > > > > > > or > > > > >
Re: [PATCH v4] Documentation: Input: Add uinput documentation
On Mon, Mar 27, 2017 at 09:01:19PM -0300, Marcos Paulo de Souza wrote:
> Signed-off-by: Marcos Paulo de Souza
> ---
>
> v3 -> v4:
> Add comment and a sleep call before UI_DEV_DESTROY (requested by Peter)
> On emit function, add an fd parameter, avoiding global variables
> Check return of ioctl related to older kernels that don't have UI_GET_VERSION
> Fix typos
>
> v2 -> v3
> Changes in libevdev's description (suggested by Peter)
> Added uinput version check when using the old interface (suggested by Peter)
> Removed section numbers from sections, sphinx creates these indexes
> (suggestion by Jon)
>
> v1 -> v2:
> Changes all over the place, including better descriptions (suggested by
> Peter)
> Added comments about the need of a sleep call (suggested by Peter)
>
> Documentation/input/uinput.rst | 229
> +
> 1 file changed, 229 insertions(+)
> create mode 100644 Documentation/input/uinput.rst
>
> diff --git a/Documentation/input/uinput.rst b/Documentation/input/uinput.rst
> new file mode 100644
> index 000..47a5c4d
> --- /dev/null
> +++ b/Documentation/input/uinput.rst
> @@ -0,0 +1,229 @@
> +=
> +uinput module
> +=
> +
> +Introduction
> +
> +
> +uinput is a kernel module that makes it possible to emulate input devices
> from
> +userspace. By writing to the module's /dev/uinput (or /dev/input/uinput), a
> +process can create a virtual device with specific capabilities.
> +Once created, the process can send events through that virtual device.
> +
> +Interface
> +=
> +
> +::
> +
> + linux/uinput.h
> +
> +The uinput header defines ioctls to create, setup and destroy virtual
> devices.
> +
> +libevdev
> +
> +
> +libevdev is a wrapper library for evdev devices that provides interfaces to
> +create uinput devices and send events. libevdev is less error-prone than
> +accessing uinput directly and should be considered for new software
> +
> +For examples and more information about libevdev:
> +https://www.freedesktop.org/software/libevdev/doc/latest/
> +
> +Examples
> +
> +
> +Keyboard events
> +---
> +
> +This first example shows how to create a new virtual device and how to send a
> +key event. All default imports and error handlers were removed for the sake
> of
> +simplicity.
> +
> +.. code-block:: c
> +
> + #include
> +
> + void emit(int fd, int type, int code, int val)
> + {
> + struct input_event ie;
> +
> + ie.type = type;
> + ie.code = code;
> + ie.value = val;
> + /* below timestamp values are ignored */
> + ie.time.tv_sec = 0;
> + ie.time.tv_usec = 0;
> +
> + write(fd, &ie, sizeof(ie));
> + }
> +
> + int main(void)
> + {
> + struct uinput_setup usetup;
> +
> + int fd = open("/dev/uinput", O_WRONLY | O_NONBLOCK);
> +
> + /* the ioctls below enables the to be created device to send key
> + * events, in this case the space key
> + */
> + ioctl(fd, UI_SET_EVBIT, EV_KEY);
> + ioctl(fd, UI_SET_KEYBIT, KEY_SPACE);
> +
> + memset(&usetup, 0, sizeof(usetup));
> + usetup.id.bustype = BUS_USB;
> + usetup.id.vendor = 0x1234; /* sample vendor */
> + usetup.id.product = 0x5678; /* sample product */
> + strcpy(usetup.name, "Example device");
> +
> + ioctl(fd, UI_DEV_SETUP, &usetup);
> + ioctl(fd, UI_DEV_CREATE);
> +
> + /*
> + * On UI_DEV_CREATE the kernel creates the device nodes for this
> device.
> + * Insert a pause so that userspace has time to detect, initialize the
> + * new device, and can start to listen to events from this device
> + */
> + sleep(1);
> +
> + /* key press, report the event, send key release, and report again */
> + emit(fd, EV_KEY, KEY_SPACE, 1);
> + emit(fd, EV_SYN, SYN_REPORT, 0);
> + emit(fd, EV_KEY, KEY_SPACE, 0);
> + emit(fd, EV_SYN, SYN_REPORT, 0);
> +
> + /* Give userspace some time to read the events before we destroy the
> + * device with UI_DEV_DESTOY
> + */
> + sleep(1);
> +
> + ioctl(fd, UI_DEV_DESTROY);
> + close(fd);
> +
> + return 0;
> + }
> +
> +Mouse movements
> +---
> +
> +This example shows how to create a virtual device that behaves like a
> physical
> +mouse.
> +
> +.. code-block:: c
> +
> + #include
> +
> + /* emit function is identical to of the first example */
> +
> + int main(void)
> + {
> + struct uinput_setup usetup;
> + int i = 50;
> +
> + int fd = open("/dev/uinput", O_WRONLY | O_NONBLOCK);
> +
> + /* enable mouse button left and relative events */
> + ioctl(fd, UI_SET_EVBIT, EV_KEY);
> + ioctl(fd, UI_SET_KEYBIT, BTN_LEFT);
> +
> + ioctl(fd, UI_SET_EVBIT, EV_REL);
> + ioctl(fd, UI_SET_RELBIT, REL_X);
> + ioctl(fd, UI_SET_RELBIT, REL_Y);
> +
> + memset(&usetup, 0, sizeof(usetup));
> + usetup.id.bustype = BUS_USB;
> + us
Re: [PATCH v3] Documentation: Input: Add uinput documentation
On Sun, Mar 26, 2017 at 01:48:12PM -0300, Marcos Paulo de Souza wrote:
> Signed-off-by: Marcos Paulo de Souza
> ---
> v2 -> v3:
> Changes in libevdev's description (suggested by Peter)
> Added uinput version check when using the old interface (suggested by Peter)
> Removed section numbers from sections, sphinx creates these indexes
> (suggestion by Jon)
>
> v1 -> v2:
> Changes all over the place, including better descriptions (suggested by
> Peter)
> Added comments about the need of a sleep call (suggested by Peter)
>
[...]
tested mouse/keyboard - works as expected, thanks. I found it slightly
confusing though that the mouse example wasn't wrapped in main() but still had a
return 0 at the bottom. This code will never change once it's in the doc, so
I'm not sure skipping things is really that useful here.
> +uinput old interface
> +
> +
> +Before uinput version 5, there wasn't a proper ioctl to setup a virtual
> device.
> +In this case, the user neesa to fill a different struct and call write o the
> +uinput file descriptor to configure the new uinput device.
> +
> +.. code-block:: c
> +
> +#include
> +
> +/* emit function is identical to of the first example */
> +
> +struct uinput_user_dev uud;
> +int version;
> +
> +fd = open("/dev/uinput", O_WRONLY | O_NONBLOCK);
> +ioctl(fd, UI_GET_VERSION, &version);
> +
> +if (version < 5) {
this won't work on all kernels. UI_GET_VERSION was added in version 4, on
kernels before you get rc == -1 and errno EINVAL. You can only check
for >= 4. Please make sure the example compiles and works on an older
kernel, otherwise there's no point shipping it.
Cheers,
Peter
> +/*
> + * the ioctls below enables the to be created device to key
> + * events, in this case the space key
> + */
> +ioctl(fd, UI_SET_EVBIT, EV_KEY);
> +ioctl(fd, UI_SET_KEYBIT, KEY_SPACE);
> +
> +memset(&uud, 0, sizeof(uud));
> +snprintf(uud.name, UINPUT_MAX_NAME_SIZE, "uinput old interface");
> +write(fd, &uud, sizeof(uud));
> +
> +ioctl(fd, UI_DEV_CREATE);
> +
> +/*
> + * On UI_DEV_CREATE the kernel creates the device nodes for this
> device.
> + * Insert a pause so that userspace has time to detect, initialize
> the
> + * new device, and can start to listen to events from this device
> + */
> +sleep(1);
> +
> +/* key press, report the event, send key release, and report again */
> +emit(EV_KEY, KEY_SPACE, 1);
> +emit(EV_SYN, SYN_REPORT, 0);
> +emit(EV_KEY, KEY_SPACE, 0);
> +emit(EV_SYN, SYN_REPORT, 0);
> +
> +ioctl(fd, UI_DEV_DESTROY);
> +}
> +
> +close(fd);
> +
> +return 0;
> +
> --
> 2.9.3
>
Re: [PATCH v2] Documentation: Input: Add uinput documentation
On Sun, Mar 26, 2017 at 01:21:14PM -0300, Marcos Paulo de Souza wrote:
> On Fri, Mar 24, 2017 at 02:39:13PM +1000, Peter Hutterer wrote:
> > as usual, reading through these things multiple times means one spots a
> > couple of different things. sorry about that.
> >
> > On Fri, Mar 24, 2017 at 12:34:59AM -0300, Marcos Paulo de Souza wrote:
> > > Signed-off-by: Marcos Paulo de Souza
> > > ---
> > > Documentation/input/uinput.rst | 196
> > > +
> > > 1 file changed, 196 insertions(+)
> > > create mode 100644 Documentation/input/uinput.rst
> > >
> > > diff --git a/Documentation/input/uinput.rst
> > > b/Documentation/input/uinput.rst
> > > new file mode 100644
> > > index 000..eb79b77
> > > --- /dev/null
> > > +++ b/Documentation/input/uinput.rst
> > > @@ -0,0 +1,196 @@
> > > +=
> > > +uinput module
> > > +=
> > > +
> > > +Introduction
> > > +
> > > +
> > > +uinput is a kernel module that makes possible to create and handle input
> > > devices
> >
> > typo: makes *it* possible.
> >
> > replace "to create and handle" with "to emulate", the rest is in the next
> > sentence anyway
>
> Fixed.
>
> >
> > > +from userspace. By writing to the module's /dev/uinput (or
> > > /dev/input/uinput), a
> > > +process can create a virtual device with specific capabilities.
> > > +Once created, the process can send events through that virtual device.
> > > +
> > > +Interface
> > > +=
> > > +
> > > +::
> > > +
> > > + linux/uinput.h
> > > +
> > > +The uinput header defines ioctls to create, setup and destroy virtual
> > > devices.
> > > +
> > > +libevdev
> > > +
> > > +
> > > +libevdev is a wrapper library for evdev devices, making uinput setup
> > > easier
> > > +by skipping a lot of ioctl calls. When dealing with uinput, libevdev is
> > > the best
> > > +alternative over accessing uinput directly, and it is less error prone.
> >
> > "libevdev is a wrapper library for evdev devices that provides interfaces to
> > create uinput devices and send events. libevdev is less error-prone than
> > accessing uinput directly and should be considered for new software".
>
> Much better. Fixed.
>
> >
> > > +
> > > +For examples and more information about libevdev:
> > > +https://cgit.freedesktop.org/libevdev
> > > +
> >
> > Please use https://www.freedesktop.org/software/libevdev/doc/latest/
> > (which needs a link to the git repo, I'll fix that in a minute)
>
> Fixed.
>
> >
> > > +Examples
> > > +
> > > +
> > > +1.0 Keyboard events
> > > +---
> > > +
> > > +This first example shows how to create a new virtual device and how to
> > > send a
> > > +key event. All default imports and error handlers were removed for the
> > > sake of
> > > +simplicity.
> > > +
> > > +.. code-block:: c
> > > +
> > > + #include
> > > +
> > > + int fd;
> > > +
> > > + void emit(int type, int code, int val)
> > > + {
> > > +struct input_event ie;
> > > +
> > > +ie.type = type;
> > > +ie.code = code;
> > > +ie.value = val;
> > > +/* below timestamp values are ignored */
> > > +ie.time.tv_sec = 0;
> > > +ie.time.tv_usec = 0;
> > > +
> > > +write(fd, &ie, sizeof(ie));
> > > + }
> > > +
> > > + int main() {
> > > +struct uinput_setup usetup;
> > > +
> > > +fd = open("/dev/uinput", O_WRONLY | O_NONBLOCK);
> > > +
> > > +/* the ioctls below enables the to be created device to key
> > > + * events, in this case the space key
> > > + **/
> >
> > the comment terminator doesn't look right
>
> Fixed.
>
> >
> > > +ioctl(fd, UI_SET_EVBIT, EV_KEY);
> > > +ioctl(fd, UI_SET_KEYBIT, KEY_SPACE);
> > > +
> > > +memset(&usetup, 0, sizeof(usetup));
> > > +usetup.id.bustype = BUS_USB;
> > > +
Re: [PATCH v2] Documentation: Input: Add uinput documentation
as usual, reading through these things multiple times means one spots a
couple of different things. sorry about that.
On Fri, Mar 24, 2017 at 12:34:59AM -0300, Marcos Paulo de Souza wrote:
> Signed-off-by: Marcos Paulo de Souza
> ---
> Documentation/input/uinput.rst | 196
> +
> 1 file changed, 196 insertions(+)
> create mode 100644 Documentation/input/uinput.rst
>
> diff --git a/Documentation/input/uinput.rst b/Documentation/input/uinput.rst
> new file mode 100644
> index 000..eb79b77
> --- /dev/null
> +++ b/Documentation/input/uinput.rst
> @@ -0,0 +1,196 @@
> +=
> +uinput module
> +=
> +
> +Introduction
> +
> +
> +uinput is a kernel module that makes possible to create and handle input
> devices
typo: makes *it* possible.
replace "to create and handle" with "to emulate", the rest is in the next
sentence anyway
> +from userspace. By writing to the module's /dev/uinput (or
> /dev/input/uinput), a
> +process can create a virtual device with specific capabilities.
> +Once created, the process can send events through that virtual device.
> +
> +Interface
> +=
> +
> +::
> +
> + linux/uinput.h
> +
> +The uinput header defines ioctls to create, setup and destroy virtual
> devices.
> +
> +libevdev
> +
> +
> +libevdev is a wrapper library for evdev devices, making uinput setup easier
> +by skipping a lot of ioctl calls. When dealing with uinput, libevdev is the
> best
> +alternative over accessing uinput directly, and it is less error prone.
"libevdev is a wrapper library for evdev devices that provides interfaces to
create uinput devices and send events. libevdev is less error-prone than
accessing uinput directly and should be considered for new software".
> +
> +For examples and more information about libevdev:
> +https://cgit.freedesktop.org/libevdev
> +
Please use https://www.freedesktop.org/software/libevdev/doc/latest/
(which needs a link to the git repo, I'll fix that in a minute)
> +Examples
> +
> +
> +1.0 Keyboard events
> +---
> +
> +This first example shows how to create a new virtual device and how to send a
> +key event. All default imports and error handlers were removed for the sake
> of
> +simplicity.
> +
> +.. code-block:: c
> +
> + #include
> +
> + int fd;
> +
> + void emit(int type, int code, int val)
> + {
> +struct input_event ie;
> +
> +ie.type = type;
> +ie.code = code;
> +ie.value = val;
> +/* below timestamp values are ignored */
> +ie.time.tv_sec = 0;
> +ie.time.tv_usec = 0;
> +
> +write(fd, &ie, sizeof(ie));
> + }
> +
> + int main() {
> +struct uinput_setup usetup;
> +
> +fd = open("/dev/uinput", O_WRONLY | O_NONBLOCK);
> +
> +/* the ioctls below enables the to be created device to key
> + * events, in this case the space key
> + **/
the comment terminator doesn't look right
> +ioctl(fd, UI_SET_EVBIT, EV_KEY);
> +ioctl(fd, UI_SET_KEYBIT, KEY_SPACE);
> +
> +memset(&usetup, 0, sizeof(usetup));
> +usetup.id.bustype = BUS_USB;
> +usetup.id.vendor = 0x1234; /* sample vendor */
add a sample product id too please
> +strcpy(usetup.name, "Example device");
> +
> +ioctl(fd, UI_DEV_SETUP, &usetup);
> +ioctl(fd, UI_DEV_CREATE);
> +
> +/* UI_DEV_CREATE causes the kernel to create the device nodes for
> this
"On UI_DEV_CREATE the kernel creates the device nodes..."
> + * device. Insert a pause so that userspace has time to detect,
> + * initialize the new device, and can start to listen to events from
> + * this device
> + **/
the comment terminator doesn't look right
note: the actual pause is missing now :)
> +
> +/* key press, report the event, send key release, and report again */
> +emit(EV_KEY, KEY_SPACE, 1);
> +emit(EV_SYN, SYN_REPORT, 0);
> +emit(EV_KEY, KEY_SPACE, 0);
> +emit(EV_SYN, SYN_REPORT, 0);
come to think of it, you probably need a pause here too, iirc a caller may
get ENODEV before reading the key events otherwise.
> +
> +ioctl(fd, UI_DEV_DESTROY);
> +close(fd);
> +
> +return 0;
> + }
> +
> +2.0 Mouse movements
> +---
> +
> +This example shows how to create a virtual device that behaves like a
> physical
> +mouse.
> +
> +.. code-block:: c
> +
> +#include
> +
> +/* emit function is identical to of the first example */
> +
> +struct uinput_setup usetup;
> +int i = 50;
> +
> +fd = open("/dev/uinput", O_WRONLY | O_NONBLOCK);
> +
> +/* enable mouse button left and relative events */
> +ioctl(fd, UI_SET_EVBIT, EV_KEY);
> +ioctl(fd, UI_SET_KEYBIT, BTN_LEFT);
> +
> +ioctl(fd, UI_SET_EVBIT, EV_REL);
> +ioctl(fd, UI_SET_RELBIT, REL_X);
> +ioctl(fd, UI_SET_RELBIT, REL_Y);
> +
> +memset(&usetup, 0, siz
Re: [PATCH] Documentation: Input: Add uinput documentation
On Wed, Mar 22, 2017 at 11:54:48PM -0300, Marcos Paulo de Souza wrote: > Hi Peter, > > first of all, thanks a lot for reading this patch so quickly and to > point a lot of things to make this doc way better. > > See some notes below. thanks for all the fixes, much appreciated. just two comments below: > On Wed, Mar 22, 2017 at 02:03:31PM +1000, Peter Hutterer wrote: [...] > > > +memset(&ie, 0, sizeof(ie)); > > > +ie.type = type; > > > +ie.code = code; > > > +ie.value = val; > > > + > > > > memset followed by three out of five filled in seems strange. Just add > > ie.time.tv_sec = 0; > > ie.time.tv_usec = 0; > > > > ideally, with a comment that states that the timestamp is ignored :) > > All the code in this doc is the result of my tests using uinput, so > somethings were set in my code some time ago and were never touched > again. Yes, this makes things a way better :) note that if we ship this as documentation, these become the official examples so they *have* to be correct. How many times have you copied something from the examples of a library? Not ideal if there's a bug or just messy code to begin with :) > I fixed a lot of things today, the things that are still missing are the > libevdev example, and the version check. I do think that I can send a > new version tomorrow. As for libevdev: just add a link to the documentation, don't add a libevdev example. libevdev should (and does) provide the examples and you don't want to ship example code that relies on some other library' API. Cheers, Peter
Re: [PATCH] Documentation: Input: Add uinput documentation
Thanks for this, I'm getting enough questions about this, so it's nice to
have a link :)
First comment: I don't think rst requires unwrapped lines, so please break
those up.
Second comment: I'd really like to have a link to libevdev here. It has a
uinput interface that's a bit more obvious and takes some of the guesswork
out. While it's good to have documentation for the kernel module,
application authors should really use libevdev's uinput interface.
On Tue, Mar 21, 2017 at 11:58:17PM -0300, Marcos Paulo de Souza wrote:
> Signed-off-by: Marcos Paulo de Souza
> ---
> Documentation/input/uinput.rst | 158
> +
> 1 file changed, 158 insertions(+)
> create mode 100644 Documentation/input/uinput.rst
>
> diff --git a/Documentation/input/uinput.rst b/Documentation/input/uinput.rst
> new file mode 100644
> index 000..8d59c98
> --- /dev/null
> +++ b/Documentation/input/uinput.rst
> @@ -0,0 +1,158 @@
> +=
> +uinput module
> +=
> +
> +Introduction
> +
> +
> +uinput is a kernel module that makes possible create and handle input
typo: "that makes it possible to ..."
> devices from userspace. By using /dev/uinput (or /dev/input/uinput), a
> process can create virtual devices and emit events like key pressing,
> mouse movements and joystick buttons.
I'd say something like this: "By writing to the module's /dev/uinput (or
/dev/input/uinput) file, a process can create a virtual device with specific
capabilities. Once created, the process can send events through that virtual
device."
> +
> +Interface
> +=
> +
> +::
> +
> + linux/uinput.h
> +
> +The uinput header defines ioctl request keys to create, setup and destroy
> virtual devices, along with ioctls specific to uinput devices, like enabling
> events and keys to be send to the kernel.
'request keys' - is this the official name for ioctl numbers? If not, let's
just use "define ioctls" or "ioctl numbers" or something, because the term
"keys" is heavily overloaded. And anything after "along with... " is
superfluous.
> +
> +Examples
> +
> +
> +1.0 Keyboard events
> +---
> +
> +This first example shows how to create a new virtual device and how to
> send a key event as well as a physical keyboard. All default imports and
"as well as" in english usually means "in addition". Just skip the part
after "send a key event".
> error handlers were removed for the sake of simplicity.
> +
> +.. code-block:: c
> +
> + #include
> +
> + int fd;
> +
> + void emit(int type, int code, int val)
> + {
> +struct input_event ie;
empty line here.
> +memset(&ie, 0, sizeof(ie));
> +ie.type = type;
> +ie.code = code;
> +ie.value = val;
> +
memset followed by three out of five filled in seems strange. Just add
ie.time.tv_sec = 0;
ie.time.tv_usec = 0;
ideally, with a comment that states that the timestamp is ignored :)
> +if (write(fd, &ie, sizeof(ie)) < 0) {
> +perror("write2");
> +exit(1);
> +}
> + }
> +
> + int main() {
> +struct input_id uid;
> +struct uinput_setup usetup;
> +
> +fd = open("/dev/uinput", O_WRONLY | O_NONBLOCK);
Empty line here to separate the open from the actual setup. And a comment
explaining what this does wouldn't go amiss.
> +ioctl(fd, UI_SET_EVBIT, EV_KEY);
> +ioctl(fd, UI_SET_KEYBIT, KEY_SPACE);
> +
> +memset(&uid, 0, sizeof(iod));
> +memset(&usetup, 0, sizeof(usetup));
> +usetup.id = uid;
this is a bit strange - you're memsetting the id field anyway with the
usetup memset - it's superfluous. Given this is supposed to be example code,
something immediately obvious would help:
usetup.id.bustype = BUS_USB;
usetup.id.vendor = 0x1234; /* sample vendor */
...
> +strcpy(usetup.name, "ex_device");
Surely we have enough bytes to name this "Example device" for obviousness :)
> +
> +ioctl(fd, UI_DEV_SETUP, &usetup);
> +ioctl(fd, UI_DEV_CREATE);
> +
> +/* wait some time until the Window Manager can get the reference for
> the
> + * new virtual device to receive data from
> + * */
> +sleep(1);
This needs to be more generic, because the WM is the last thing that
actually cares about the device.
"UI_DEV_CREATE causes the kernel to create the device nodes for this device.
Insert a pause so that userspace has time to detect, initialize the new
device, and can start to listen to events from this device."
> +
> +/* send key press, report the event, send key release, and report
> again */
> +emit(EV_KEY, KEY_SPACE, 1);
> +emit(EV_SYN, SYN_REPORT, 0);
> +emit(EV_KEY, KEY_SPACE, 0);
> +emit(EV_SYN, SYN_REPORT, 0);
UI_DEV_DESTROY is missing
> +
> +close(fd);
> +
> +return 0;
> + }
> +
> +2.0 Mouse movements
> +---
> +
> +This example show
Re: [PATCH] Input: synaptics-rmi4 - Report slot as inactive when contact is a palm
On Thu, Mar 16, 2017 at 05:52:07PM -0700, Andrew Duggan wrote:
> On 03/16/2017 05:04 PM, Dmitry Torokhov wrote:
> > On Thu, Mar 16, 2017 at 04:56:31PM -0700, Andrew Duggan wrote:
> > > When the firmware identifies a contact as a palm the driver sets the tool
> > > type to MT_TOOL_PALM, but sets the slot state as active. Reporting the
> > > palm as active results in userspace input libraries considering the palm
> > > as a valid contact. Touchpads which previously were using hid-multitouch
> > > are now not suppressing palms when switching to the RMI4 driver. This
> > > change fixes palm rejection when using the RMI4 driver.
> > >
> > > Signed-off-by: Andrew Duggan
> > > Tested-by: Cameron Gutman
> > > ---
> > > drivers/input/rmi4/rmi_2d_sensor.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/input/rmi4/rmi_2d_sensor.c
> > > b/drivers/input/rmi4/rmi_2d_sensor.c
> > > index 8bb866c..8d1f295 100644
> > > --- a/drivers/input/rmi4/rmi_2d_sensor.c
> > > +++ b/drivers/input/rmi4/rmi_2d_sensor.c
> > > @@ -80,7 +80,8 @@ void rmi_2d_sensor_abs_report(struct rmi_2d_sensor
> > > *sensor,
> > > input_mt_slot(input, slot);
> > > input_mt_report_slot_state(input, obj->mt_tool,
> > > -obj->type != RMI_2D_OBJECT_NONE);
> > > +(obj->type != RMI_2D_OBJECT_NONE)
> > > +&& (obj->type != RMI_2D_OBJECT_PALM));
> > > if (obj->type != RMI_2D_OBJECT_NONE) {
> > > obj->x = sensor->tracking_pos[slot].x;
> > If we are relying on hardware to do palm rejection, then we should not
> > be reporting the rest of the events for palm either (i.e. the condition
> > in the if statement above should also be updated).
> >
> > But I do not understand why userspace doe snot do the right thing? Yes,
> > the slot is active, but reported contact type is MT_TOOL_PALM, so it
> > knows what it deals with.
> >
> > Thanks.
> >
> My intent is to notify userspace that there is a palm present. But, if
> userspace does not have code which explicitly handles the MT_TOOL_PALM type
> it won't be considered a finger. I think it is only recently that drivers
> have started reporting MT_TOOL_PALM to userspace so I'm not sure if
> libraries like libinput make use of it yet.
>
> Starting with v4.11 some touchpads will be switching from hid-multitouch to
> the RMI4 driver and reporting palms as active results in unsuppressed palms.
> I want to avoid users from upgrading and experiencing a degradation in
> usability. In which case I can update the if statement and resubmit. This is
> basically how hid-multitouch is handling it. Maybe in the future we can add
> a parameter to enable reporting palms to userspace.
Can you send me an evemu record of that happening please? I need to see the
exact instance, e.g. when it's set, what's set before, etc. Ideally just
attach to bug 100243, thanks.
Cheers,
Peter
Re: Synaptics RMI4 touchpad regression in 4.11-rc1
On Fri, Mar 17, 2017 at 12:23:36PM -0700, Andrew Duggan wrote: > On 03/17/2017 09:57 AM, Benjamin Tissoires wrote: > > On Wed, Mar 15, 2017 at 2:19 AM, Andrew Duggan > > wrote: > > > On 03/13/2017 10:10 PM, Cameron Gutman wrote: > > > > > > > > On 03/13/2017 06:35 PM, Andrew Duggan wrote: > > > > > > > > > > On 03/13/2017 06:15 AM, Benjamin Tissoires wrote: > > > > > > [Resending, forgot to add Jiri in CC] > > > > > > > > > > > > On Mar 13 2017 or thereabouts, Benjamin Tissoires wrote: > > > > > > > On Mar 13 2017 or thereabouts, Thorsten Leemhuis wrote: > > > > > > > > Lo! On 12.03.2017 02:55, Cameron Gutman wrote: > > > > > > > > > Beginning in 4.11-rc1, it looks like RMI4 is binding to my > > > > > > > > > XPS 13 > > > > > > > > > 9343's > > > > > > > > > Synaptics touchpad and dropping some errors into dmesg. Here > > > > > > > > > are the > > > > > > > > > messages that seem RMI-related: > > > > > > > > > > > > > > > > > > rmi4_f34 rmi4-00.fn34: rmi_f34v7_probe: Unrecognized > > > > > > > > > bootloader > > > > > > > > > version > > > > > > > > > rmi4_f34: probe of rmi4-00.fn34 failed with error -22 > > > > > > > > > rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: > > > > > > > > > Synaptics, > > > > > > > > > product: TM3038-001, fw id: 1832324 > > > > > > > > > input: Synaptics TM3038-001 as > > > > > > > > > /devices/pci:00/INT3433:00/i2c-7/i2c-DLL0665:01/0018:06CB:76AD.0001/input/input19 > > > > > > > > > hid-rmi 0018:06CB:76AD.0001: input,hidraw0: I2C HID v1.00 > > > > > > > > > Mouse > > > > > > > > > [DLL0665:01 06CB:76AD] on i2c-DLL0665:01 > > > > > > > > FWIW, I get this on my XPS 13 DE (9360) with 4.11-rc1: > > > > > > > > > > > > > > > > input: SynPS/2 Synaptics TouchPad as > > > > > > > > /devices/platform/i8042/serio1/input/input6 > > > > > > > > rmi4_f34 rmi4-00.fn34: rmi_f34v7_probe: Unrecognized bootloader > > > > > > > > version > > > > > > > > rmi4_f34: probe of rmi4-00.fn34 failed with error -22 > > > > > > > > rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: > > > > > > > > Synaptics, > > > > > > > > product: TM3038-003, fw id: 2375007 > > > > > > > > input: Synaptics TM3038-003 as > > > > > > > > > > > > > > > > /devices/pci:00/:00:15.1/i2c_designware.1/i2c-8/i2c-DLL075B:01/0018:06CB:76AF.0001/input/input20 > > > > > > > > hid-rmi 0018:06CB:76AF.0001: input,hidraw0: I2C HID v1.00 Mouse > > > > > > > > [DLL075B:01 06CB:76AF] on i2c-DLL075B:01 > > > > > > > > > > > > > > > > > […] > > > > > > > > > Compared to hid-multitouch, the RMI stack seems to have > > > > > > > > > completely > > > > > > > > > broken > > > > > > > > > palm rejection and introduced some random jumpiness during > > > > > > > > > fine > > > > > > > > > pointing > > > > > > > > > motions. I don't know if these issues are caused by the above > > > > > > > > > errors > > > > > > > > > or > > > > > > > > > are a separate issue. > > > > > The error about the bootloader version not being recognized just means > > > > > that updating the firmware is not supported on this touchpad. It is > > > > > only the > > > > > F34 firmware update functionality which is failing to load. The palm > > > > > rejection and jumps are not related to this error. > > > > > > > > > Maybe that code path should be changed to not make as much noise when it > > > > runs > > > > on known unsupported hardware. Something like the attached patch? > > > > > > > > > Looking at how hid-multitouch handles palms it looks like palms should > > > > > not be reported as active when calling input_mt_report_slot_state(). > > > > > I'm > > > > > setting the tool type to MT_TOOL_PALM when the firmware determines > > > > > that a > > > > > contact is a palm. But, that does not seem to be sufficient enough to > > > > > have > > > > > the palms filtered out. After some quick testing it looks like the > > > > > change > > > > > below will restore palm rejection similar to that provided by > > > > > hid-multitouch. > > > > > > > > > It looks like your email client ate the tabs, but if I apply the change > > > > myself it seems to fix the palm rejection regression for me. > > > > > > > > Tested-by: Cameron Gutman > > > > > > Sorry, I was short on time and just copied the diff into the email. I'll > > > submit a proper patch soon with your tested-by included. Thanks for > > > testing. > > > > > > > > I just pointed out this patch (well the actual submission) to Jason > > (Cc-ed). Given that there is no proper handling of MT_TOOL_PALM yet in > > userspace, I thought it was the easiest way. > > However, it seems that this doesn't enhance the jumps and just make it > > worse. > > I was assuming that the jumps and palm rejection where two separate issues. > But, the palm rejection patch makes things worse? > > > Is there anything we can do to fix it (besides temporary disabling the > > automatic loading of hid-rmi)? > > I do not have a fix for the jumps yet. My next step is to file a bug against > libinput or th
Re: [PATCH] Input: synaptics-rmi4 - Report slot as inactive when contact is a palm
On Thu, Mar 16, 2017 at 05:04:50PM -0700, Dmitry Torokhov wrote:
> On Thu, Mar 16, 2017 at 04:56:31PM -0700, Andrew Duggan wrote:
> > When the firmware identifies a contact as a palm the driver sets the tool
> > type to MT_TOOL_PALM, but sets the slot state as active. Reporting the
> > palm as active results in userspace input libraries considering the palm
> > as a valid contact. Touchpads which previously were using hid-multitouch
> > are now not suppressing palms when switching to the RMI4 driver. This
> > change fixes palm rejection when using the RMI4 driver.
> >
> > Signed-off-by: Andrew Duggan
> > Tested-by: Cameron Gutman
> > ---
> > drivers/input/rmi4/rmi_2d_sensor.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/input/rmi4/rmi_2d_sensor.c
> > b/drivers/input/rmi4/rmi_2d_sensor.c
> > index 8bb866c..8d1f295 100644
> > --- a/drivers/input/rmi4/rmi_2d_sensor.c
> > +++ b/drivers/input/rmi4/rmi_2d_sensor.c
> > @@ -80,7 +80,8 @@ void rmi_2d_sensor_abs_report(struct rmi_2d_sensor
> > *sensor,
> > input_mt_slot(input, slot);
> >
> > input_mt_report_slot_state(input, obj->mt_tool,
> > - obj->type != RMI_2D_OBJECT_NONE);
> > + (obj->type != RMI_2D_OBJECT_NONE)
> > + && (obj->type != RMI_2D_OBJECT_PALM));
> >
> > if (obj->type != RMI_2D_OBJECT_NONE) {
> > obj->x = sensor->tracking_pos[slot].x;
>
> If we are relying on hardware to do palm rejection, then we should not
> be reporting the rest of the events for palm either (i.e. the condition
> in the if statement above should also be updated).
>
> But I do not understand why userspace doe snot do the right thing? Yes,
> the slot is active, but reported contact type is MT_TOOL_PALM, so it
> knows what it deals with.
oops, filed: https://bugs.freedesktop.org/show_bug.cgi?id=100243
until RMI4 we had no drivers setting that tool type and we still don't have
rull RMI4 in the released kernels, so it was a simple oversight.
mind you, that only applies for libinput, not hedging my bets on the
synaptics driver here.
Cheers,
Peter
Re: [GIT PULL] HID for 4.11
On Tue, Feb 28, 2017 at 06:31:10PM -0800, Andrew Duggan wrote: > On 02/28/2017 04:56 PM, Linus Torvalds wrote: > > On Mon, Feb 20, 2017 at 8:37 PM, Linus Torvalds > > wrote: > > > Yeah, so enabling HID_RMI makes my touchpad work again. > > .. so I just noticed something: it works subtly differently. > > > > When I drag something around, I mostly just double-tap and move, and > > that still works fine. > > > > But sometimes I click (and hold) with one finger, and then move around > > with another. That's occasionally very useful when you move longer > > distances, because you can just raise and move that other finger > > multiple times. > > > > That doesn't seem to work with the RMI driver. I seem to get scroll > > events instead. fwiw, scroll events are implemented in userspace, so this would be a bug in libinput or the synaptics driver if you're using that one. > > I'm sure there's some setting for mouse gestures. But it's a bit odd > > when they change just because the driver changes. And gnome certainly > > doesn't believe in settings, because these things are obviously > > "intuitive". > > > > Ideas? Or am I just dreaming, and the click-and-move never worked? > > Because I'm pretty sure it did, but sometimes the meds kick in. it definitely should work and it shouldn't be affected much by these kernel driver changes. more specifically, scrolling should never happen while BTN_LEFT is down. > The RMI driver does report input events a little differently then the > hid-multitouch driver. It may report different min / max values for axis, > different resolution values, and it also reports ABS_MT_PRESSURE. Also, > depending on how the touchpad's firmware was configured it may also report > additional fingers. It probably also reports a few other properties which > hid-multitouch does not. Since it is the input handling libraries in > userspace which interpret the input events and decide what is a drag and > what is a scroll I suspect the issue may be in userspace. The additional > properties reported by the input device may be causing the input handler to > potentially misidentify the device and treat it differently. That's at least > where I would start looking. > > For what it's worth, I'm using libinput and the RMI driver on my touchpad. > Click and drag works well with libinput's "ClickMethod" parameter set to > "clickfinger". fwiw, should work with software buttons as well. but as I said above, scroll events should never trigger as long as a button is down, at least not with only two fingers on the touchpad. I suspect you're just triggering a bug that wasn't triggered by the ps/2 emulation. you can run linput-debug-events --verbose and have a look at the various state debugging information, that may hint at what's going on (e.g. a finger mistaken as palm touch, or something). Or record one such interaction with evemu-record and send it to me (preferrably here [1], if you're using libinput). Also, what version of libinput/synaptics are you on? Cheers, Peter [1] https://bugs.freedesktop.org/enter_bug.cgi?product=wayland&component=libinput
Re: [PATCH] Input: mousedev - stop offering PS/2 to userspace by default
On 30/12/2016 04:07 , Dmitry Torokhov wrote: Evdev interface has been available for many years and by now everyone is switched to using it, so let's stop offering /dev/input/mouseN and /dev/psaux by default. Signed-off-by: Dmitry Torokhov Acked-by: Peter Hutterer Cheers, Peter --- drivers/input/Kconfig | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/input/Kconfig b/drivers/input/Kconfig index 6261874..ff80377 100644 --- a/drivers/input/Kconfig +++ b/drivers/input/Kconfig @@ -94,7 +94,6 @@ comment "Userland interfaces" config INPUT_MOUSEDEV tristate "Mouse interface" - default y help Say Y here if you want your mouse to be accessible as char devices 13:32+ - /dev/input/mouseX and 13:63 - /dev/input/mice as an @@ -109,7 +108,6 @@ config INPUT_MOUSEDEV config INPUT_MOUSEDEV_PSAUX bool "Provide legacy /dev/psaux device" - default y depends on INPUT_MOUSEDEV help Say Y here if you want your mouse also be accessible as char device @@ -118,7 +116,6 @@ config INPUT_MOUSEDEV_PSAUX If unsure, say Y. - config INPUT_MOUSEDEV_SCREEN_X int "Horizontal screen resolution" depends on INPUT_MOUSEDEV
