2021-09-24 18:08:01 +02:00
|
|
|
.. _incorrectly_enabled_hires:
|
|
|
|
|
|
|
|
|
|
==============================================================================
|
|
|
|
|
Incorrectly enabled high-resolution scroll
|
|
|
|
|
==============================================================================
|
|
|
|
|
|
|
|
|
|
Some devices might announce support for high-resolution scroll wheel by enabling
|
|
|
|
|
``REL_WHEEL_HI_RES`` and/or ``REL_HWHEEL_HI_RES`` but never send a
|
|
|
|
|
high-resolution scroll event.
|
|
|
|
|
|
|
|
|
|
When the first low-resolution scroll event is received without any previous
|
|
|
|
|
high-resolution event, libinput prints a bug warning with the text **"device
|
|
|
|
|
supports high-resolution scroll but only low-resolution events have been
|
|
|
|
|
received"** and a link to this page.
|
|
|
|
|
|
|
|
|
|
.. note:: This warning will be printed only once
|
|
|
|
|
|
|
|
|
|
In most cases this is a bug on the device firmware, the kernel driver or in a
|
|
|
|
|
software used to create user-space devices through uinput.
|
|
|
|
|
|
|
|
|
|
Once the bug is detected, libinput will start emulating high-resolution scroll
|
|
|
|
|
events.
|
|
|
|
|
|
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
|
Detecting and fixing the issue
|
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
Events sent by a buggy device can be shown in the
|
|
|
|
|
:ref:`libinput record <libinput-record>` output for the device. Notice that
|
|
|
|
|
``REL_WHEEL_HI_RES`` and ``REL_HWHEEL_HI_RES`` are set but only ``REL_WHEEL``
|
|
|
|
|
events are sent: ::
|
|
|
|
|
|
|
|
|
|
# Supported Events:
|
|
|
|
|
# Event type 0 (EV_SYN)
|
|
|
|
|
# Event type 1 (EV_KEY)
|
|
|
|
|
# Event code 272 (BTN_LEFT)
|
|
|
|
|
# Event type 2 (EV_REL)
|
|
|
|
|
# Event code 0 (REL_X)
|
|
|
|
|
# Event code 1 (REL_Y)
|
|
|
|
|
# Event code 6 (REL_HWHEEL)
|
|
|
|
|
# Event code 8 (REL_WHEEL)
|
|
|
|
|
# Event code 11 (REL_WHEEL_HI_RES)
|
|
|
|
|
# Event code 12 (REL_HWHEEL_HI_RES)
|
|
|
|
|
[...]
|
|
|
|
|
quirks:
|
|
|
|
|
events:
|
|
|
|
|
- evdev:
|
|
|
|
|
- [ 0, 0, 2, 8, 1] # EV_REL / REL_WHEEL 1
|
|
|
|
|
- [ 0, 0, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +0ms
|
|
|
|
|
- evdev:
|
|
|
|
|
- [ 0, 15126, 2, 8, 1] # EV_REL / REL_WHEEL 1
|
|
|
|
|
- [ 0, 15126, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +15ms
|
|
|
|
|
- evdev:
|
|
|
|
|
- [ 0, 30250, 2, 8, 1] # EV_REL / REL_WHEEL 1
|
|
|
|
|
- [ 0, 30250, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +15ms
|
|
|
|
|
|
|
|
|
|
The issue can be fixed by adding a quirk to unset the ``REL_WHEEL_HI_RES`` and
|
|
|
|
|
``REL_HWHEEL_HI_RES`` event codes: ::
|
|
|
|
|
|
quirks: allow overriding of AttrEventCode and AttrInputProp
This switches the quirk from AttrEventCodeEnable/Disable to just
AttrEventCode with a +/- prefix for each entry.
This switches the quirk from AttrInputPropEnable/Disable to just
AttrInputProp with a +/- prefix for each entry.
Previously, both event codes and input props would only apply the
last-matching section entry for a device. Furthermore, an earlier Disable entry
would take precedence over a later Enable entry. For example, a set of
sections with these lines *should* enable left, right and middle:
[first]
AttrEventCodeEnable=BTN_LEFT;BTN_RIGHT;BTN_MIDDLE
[second]
AttrEventCodeDisable=BTN_RIGHT
[third]
AttrEventCodeEnable=BTN_LEFT;BTN_RIGHT;
Alas: the first line was effectively ignored (quirks only returned the
last-matching one, i.e. the one from "third"). And due to implementation
details in evdev.c, the Disable attribute was processed after Enable,
i.e. the device was enabled for left + right and then disabled for
right. As a result, the device only had BTN_LEFT enabled.
Fix this by changing the attribute to carry both enable/disable
information and merging the commands together.
Internally, all quirks matching a device are simply ref'd into an array
in the struct quirks. The applied value is simply the last entry in the
array corresponding to our quirk.
For AttrEventCode and AttrInputProp instead do this:
- switch them to a tuple with the code as first entry and a boolean
enable/disable as second entry
- if the struct quirk already has an entry for either, append the more
recent one to the existing entry (instead of creating a new entry in
the array). This way we have all entries that match and in-order of
precedence - i.e. we can process them left-to-right to end up
with the right state.
Fixes: https://gitlab.freedesktop.org/libinput/libinput/-/issues/821
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2022-11-15 13:53:43 +10:00
|
|
|
AttrEventCode=-REL_WHEEL_HI_RES;-REL_HWHEEL_HI_RES;
|
2021-09-24 18:08:01 +02:00
|
|
|
|
|
|
|
|
Please see :ref:`device-quirks` for details.
|
