Age | Commit message (Collapse) | Author | Files | Lines |
|
The IBM/Lenovo Scrollpoint mouse features a trackpoint-like stick that
sends a great amount of scroll deltas.
In order to handle the device, a quirk is in place to normalize the
scroll events as they were relative motion.
However, when high-resolution scroll was implemented, we started
normalizing the hi-res events instead of the lo-res events by mistake.
Fix the quirk by normalizing the right deltas.
Fixes: 6bb02aaf307a ("High-resolution scroll wheel support")
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Tested-by: Peter Ganzhorn <peter.ganzhorn@gmail.com>
|
|
On mice, switching the acceleration profile to flat disables dpi normalization,
because high or even switchable dpi are generally major features of a
high-end mouse, and switching to flat acceleration indicates that the user
wants to reduce the effects of any cursor acceleration to a minimum.
Therefore we skip normalization there and let the user take full advantage
of their expensive hardware.
On touchpads, particularly those built into a laptop, users have to deal with
whatever hardware they have; touchpad dpi is an afterthought at best, or
a disaster at worst. Switching to the flat profile is more likely to be
about avoiding the non-linear acceleration curve of the adaptive profile.
Hence the flat profile for touchpads shouldn't copy what the one for mice does,
but rather use dpi normalization like the adaptive profile. This keeps flat
acceleration on low-resolution touchpads from dropping to unusably slow speeds.
Signed-off-by: satrmb <10471-satrmb@users.noreply.gitlab.freedesktop.org>
|
|
Tools default to 1% lower threshold (tip up) and 5% upper threshold (tip
down). But our distance vs pressure exclusion would reset the distance
for *any* pressure value, regardless how low that value was and how high
distance was in comparison.
A very low pressure value of less than 1% would then result in a
normalized pressure of 0, so we'd effectively just reset the distance to
zero and do nothing with the pressure. This can cause distance jumps
when the tool arbitrarily sends low pressure values while hovering as
seen in https://github.com/libsdl-org/SDL/pull/5481#issuecomment-1118969064
Commit 61bdc05fb0f84303f97daaba6ae6b49c976dbfbf from Dec 2017
"tablet: set the tip-up pressure threshold to 1%"
was presumably to address this but no longer (?) works.
Fix this by addressing multiple issues at the same time:
- anything under that 1% threshold is now considered as zero pressure
and any distance value is kept as-is. Once pressure reaches 1%,
distance is always zero.
- axis normalization is now from 1% to 100% (previously: upper threshold
to 100%). So a tip down event should always have ~4% pressure and we
may get tablet motion events with nonzero pressure before the tip down
event.
From memory, this was always intended anyway since a tip event should
require some significant pressure, maybe too high compared to e.g.
pressure-sensitive painting
- where a tablet has an offset, add the same 1%/5% thresholds, on top of
that offset. And keep adjusting those thresholds as we change the
offset. Assuming that the offset is the absolute minimum a worn-out
pen can reach, this gives us the same behaviour as a new pen. The
calculation here uses a simple approach so the actual range is
slightly larger than 5% but it'll do.
Previously, the lower threshold for an offset pen was the axis minimum
but that can never be reached. So there was probably an undiscovered
bug in there.
And fix a bunch of comments that were either wrong, confusing or
incomplete, e.g. the pressure thresholds were already in device
coordinates.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
A few lines north of here we return early if neither bit is set. If we
get to this point, at least one bit is set so this part of the condition
always evaluates to true.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Removed in b925a0878b0b51fe30016546b9e48a7613dccd4d
quirks: switch the models with missing buttonpad to use the new attr
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
This fixes a format string vulnerabilty.
evdev_log_message() composes a format string consisting of a fixed
prefix (including the rendered device name) and the passed-in format
buffer. This format string is then passed with the arguments to the
actual log handler, which usually and eventually ends up being printf.
If the device name contains a printf-style format directive, these ended
up in the format string and thus get interpreted correctly, e.g. for a
device "Foo%sBar" the log message vs printf invocation ends up being:
evdev_log_message(device, "some message %s", "some argument");
printf("event9 - Foo%sBar: some message %s", "some argument");
This can enable an attacker to execute malicious code with the
privileges of the process using libinput.
To exploit this, an attacker needs to be able to create a kernel device
with a malicious name, e.g. through /dev/uinput or a Bluetooth device.
To fix this, convert any potential format directives in the device name
by duplicating percentages.
Pre-rendering the device to avoid the issue altogether would be nicer
but the current log level hooks do not easily allow for this. The device
name is the only user-controlled part of the format string.
A second potential issue is the sysname of the device which is also
sanitized.
This issue was found by Albin Eldstål-Ahrens and Benjamin Svensson from
Assured AB, and independently by Lukas Lamster.
Fixes #752
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
All cases we have in our code base have an otherwise unused variable to
loop through the array. Let's auto-declare this as part of the loop.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Add option to control whether the touchpad should be disabled while the
trackpoint is in use.
Fix #731
Signed-off-by: pudiva chip líquida <pudiva@skylittlesystem.org>
|
|
Declare the variables used to keep track of joystick buttons and
keyboard keys right before they are used for better readability and
consistency.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
|
|
Create a list of well-known keyboard keys containing one the most
representative key(s) of a group.
The rule is based on the assumption that if the representative key is
present, other keys of the group should be present as well.
The groups are:
- Modifiers group: KEY_LEFTCTRL.
- Character group: KEY_CAPSLOCK.
- Numeric group: KEY_NUMLOCK.
- Editing keys: KEY_INSERT.
- Multimedia keys: KEY_MUTE, KEY_CALC, KEY_FILE, KEY_MAIL,
KEY_PLAYPAUSE and KEY_BRIGHTNESSDOWN.
When 4 of these keys are found, the device is tagged as a keyboard.
Fix #745
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
|
|
to avoid conflicts with vendors reusing vid:pid try to find first by path
Signed-off-by: Alberto Fanjul <albertofanjul@gmail.com>
|
|
The changes introduced in b5b6f835af2e99b6a4e64fb0174ab551ed141763 to
add support for hold gestures introduced a regression:
The mechanism that was in place to improve the disambiguation between
two finger pinch and scroll during the beginning of the gesture stopped
working and instead a bug warning was printed on the log.
Fix the regression by allowing to go from the scroll state to the pinch
state.
Fix #726
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
|
|
Since cd4f2f32b57a ("fallback: disable mouse scroll wheel while middle
button is pressed") the mouse wheel is inhibited while the mouse wheel
is pressed.
The original intention of this feature was to avoid unintended scroll
while pressing the scroll wheel. However, now that high-resolution
scroll is fully integrated in libinput we can improve this feature and
filter unintended scroll (below half a detent) and allow it when it is
intended (over half a detent).
Remove the "WHEEL_STATE_PRESSED" state from the wheel state machine and
let the general heuristics handle this case.
Also, remove the specific tests for this feature as now it is covered
by the general test cases.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
|
|
The device sends its own scroll events when its trackpoint is moved
while the middle button is pressed.
Because scroll events are not going to be inhibited after a certain
amount of scroll is detected in a follow up commit, remove the quirk.
This reverts 53bd70f4c7e2 ("quirks: Lenovo Trackpoint Keyboard II")
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
|
|
Signed-off-by:Peter Hutterer <peter.hutterer@who-t.net>
|
|
The Wacom 524C device triggers a kernel bug in the InRange and Invert
handling. Every time BTN_TOUCH is set/unset the device also sets/unsets
BTN_TOOL_PEN even when we nominally have the eraser in proximity.
The event sequence effectively looks like this:
# on prox in
BTN_TOOL_RUBBER 1
-- SYN_REPORT ---
# on tip down
BTN_TOOL_PEN 1
BTN_TOUCH 1
-- SYN_REPORT ---
# on tip up
BTN_TOUCH 0
BTN_TOOL_PEN 0
-- SYN_REPORT ---
# on prox out
BTN_TOOL_RUBBER 1
-- SYN_REPORT ---
To work around this, bias our duplicate tool detection code towards the
eraser - if we have an eraser in-prox already and the pen goes
in-prox, ignore it and continue with the eraser. But if we have a pen
in-prox and the eraser goes in-prox as well, force a prox-out for the
pen and put the eraser in-prox.
Recording originally from
https://github.com/linuxwacom/xf86-input-wacom/issues/186
Fixes #702
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
The changes made in ca3df8a076d54a93b3c2fb8a5eea4326d487050c to improve
pinch detection introduced a regression:
When the thumb is used to press the clickpad it is automatically tagged
as thumb and the gesture state machine does not initialize it, leaving
its initial X and Y position set to 0.
When another finger is put on the clickpad, the distance moved by the
thumb is checked and because its initial position is 0 movement is
detected.
Add an additional check to take into account only thumbs that are used
in the gesture.
Fix #708
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
|
|
The most common trigger for this is the debouncing timer which is a mere
12ms and is effectively unavoidable, virtually every caller will
trigger those messages at some point.
Let's add a grace period of 20ms below which we don't log this message
to avoid logspam. And in the process, bump the equivalent warning
message up to 20ms as well.
Related #711
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
We already ratelimit the normal notification about event processing
lagging behind but in the case of timers actually expiring late, we'd
pass those messages on. So lots of clicks on a slow-reponse system
resulted in lots of messages triggered by the debounce timers.
Use the same ratelimiting as the event processing warning, 5 messages
per hour which should be a good balance between warning and not spamming
the log.
Fixes #711
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
The EVDEV_UDEV_TAG_JOYSTICK is set when a joystick or gamepad button
is found. However, it can not be used to identify joysticks or
gamepads because there are keyboards that also have it. Even worse,
many joysticks also map KEY_* and thus are tagged as keyboards.
In order to be able to detect joysticks and gamepads and
differentiate them from keyboards, apply the following rules:
1. The device is tagged as joystick but not as tablet
2. It has at least 2 joystick buttons
3. It doesn't have 10 keyboard keys
Fix #701
Fix #415
Fix #703
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
|
|
Move the logic to detect joysticks and gamepads to its own function.
Refactor, no functional changes.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
|
|
Use the previous heuristics to detect clickpads where a touchpad was
handled as a clickpad when:
- The property INPUT_PROP_BUTTONPAD is set
- The property INPUT_PROP_BUTTONPAD is NOT set but the touchpad only
has BTN_LEFT
Revert a37d6dcc9c2ec7ebd0d3609e01da1cfcec28db6e:
"touchpad: if we have a right button, let's assume it's not a clickpad"
MR: https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/614
BUG: https://gitlab.freedesktop.org/libinput/libinput/-/issues/595
Fix #704
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
|
|
Translates to the same thing, but the bit() helper is nicer and less
likely to be typoed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Follow the name convention used in evdev-wheel.c and rename the handle
event functions from "tp_gesture_[STATE]_handle_event" to
"tp_gesture_handle_event_on_state_[STATE]".
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
|
|
Most mice with high-resolution support have a mechanism in place to
adjust the wheel to a detent. When scrolling, it is possible to stop
between two detents and this mechanism could generate a small amount of
scroll in the oposite direction.
Track the scroll direction in the wheel state machine and reset it when
the direction changes to avoid this issue.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
|
|
Mice with high-resolution support can generate deltas when the finger is
put on the wheel or when the user tries to click the wheel.
To avoid sending involuntary scroll events, add an extra state the the
wheel state machine to accumulate scroll deltas.
While the accumulated scroll is lower than a certain threshold, ignore
them until the threshold is reached.
Since no finish event is sent by the mouse, reset the state machine
after a period of scroll inactivity.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
|
|
In order to be able to add more complex rules in the future, transform
the current wheel handling code into a state machine.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
|
|
Move the logic to flush wheel scroll to it's own funtion.
Refactor, no functional changes.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
|
|
Move the logic to handle wheels to its own file.
Refactor, no functional changes.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
|
|
Before hold gestures where implemented, when a thumb was detected it
was enough to reset the state machine.
However, now it is possible to detect a thumb while a hold gesture is
in course.
Cancel any ongoing gesture when a thumb is detected to avoid dropping
the gesture end event.
See #693
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
|
|
Signed-off-by: Eduardo Cruz <eduardo.cruz@kdemail.net>
|
|
Signed-off-by: Eduardo Cruz <eduardo.cruz@kdemail.net>
|
|
During the transition from GESTURE_STATE_HOLD_AND_MOTION to
GESTURE_STATE_POINTER_MOTION the last pointer motion event was
processed twice.
Fix #680
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
|
|
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, print a kernel bug warning and start
emulating high-resolution scroll events.
Fix #668
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
|
|
LIBINPUT_EVENT_GESTURE_HOLD_BEGIN and LIBINPUT_EVENT_GESTURE_HOLD_END
were missing from libinput_event_gesture_get_base_event.
Add them to avoid triggering an erroneous client bug warning.
Fix #671
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
|
|
When required, invert horizontal scrolling in evdev_notify_axis_wheel
following the QUIRK_MODEL_INVERT_HORIZONTAL_SCROLLING quirk.
Fix #669
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
|
|
External touchpads using USB are vanishingly few, built-in touchpads
that use USB are comparatively common. So let's default to internal,
for vendors like Logitech and Wacom that only make external touchpads we
have special conditions in place anyway.
Fixes #664
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
When pairing a trackpoint, use the model flags for the touchpad, don't
use a separate set of conditions.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
GTK handles LIBINPUT_EVENT_POINTER_SCROLL_CONTINUOUS as
GDK_SCROLL_SMOOTH, the same event type that is used to handle
LIBINPUT_EVENT_POINTER_SCROLL_FINGER.
Because Mutter and other compositors, like wlroots based compositors,
translate libinput terminating event to axis_stop instead of doing their
own emulation, if libinput stops sending terminating events, it will
cause client bugs.
Since libinput always sends the terminating event for trackpoints and
button scrolling and there are even tests in place to check for them,
update the documentation to guarantee the terminating scroll sequence.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
|
|
It's been a while since we really could do something about those jumps,
so let's assume most of these are informative and not a bug in libinput.
For that let's not spam the user's journal and ratelimit it to a handful
a day.
Per day because that increases the chance of an error being present in
the recent logs if the user does search for it.
Related #663
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
If a touchpad is removed before its dwt-paired keyboard, we're leaking
the keyboard struct. Fix this by cleaning up properly when our device is
removed.
This is the cause of many failed tests in the udev backend tests during
the CI valgrind run. Because we're testing the udev backend it will add
any devices created by tests run in parallel, some of which are keyboard
devices. Depening on the test completions, the keyboards may or may not
get removed before this device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Move the logic used to parse boolean quirks and udev flags to a common
function in utils.
Refactor, no functional changes.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
|
|
Starting with kernel v5.0 two new axes are available for high-resolution wheel
scrolling: REL_WHEEL_HI_RES and REL_HWHEEL_HI_RES. Both axes send data in
fractions of 120 where each multiple of 120 amounts to one logical scroll
event. Fractions of 120 indicate a wheel movement less than one detent.
This commit adds a new API for scroll events. Three new event types that encode
the axis source in the event type name and a new API to get a normalized-to-120
value that also used by Windows and the kernel (each multiple of 120 represents
a logical scroll click).
This addresses a main shortcoming with the existing API - it was unreliable to
calculate the click angle based on the axis value+discrete events and thus any
caller using the axis value alone would be left with some ambiguity. With the
v120 API it's now possible to (usually) calculate the click angle, but more
importantly it provides the simplest hw-independent way of scrolling by a
click or a fraction of a click.
A new event type is required, the only way to integrate the v120 value
otherwise was to start sending events with a discrete value of 0. This
would break existing xf86-input-libinput (divide by zero, fixed in 0.28.2) and
weston (general confusion). mutter, kwin are unaffected.
With the new API, the old POINTER_AXIS event are deprecated - callers should use
the new API where available and discard any POINTER_AXIS events.
Notable: REL_WHEEL/REL_HWHEEL are emulated by the kernel but there's no
guarantee that they'll come every accumulated 120 values, e.g. Logitech mice
often send events that don't add up to 120 per detent.
We use the kernel's wheel click emulation instead of doing our own.
libinput guarantees high-resolution events even on pre-5.0 kernels.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
|
|
The device sends its own scroll events when its trackpoint is moved
while the middle button is pressed.
Because scroll events are inhibited while the middle button is pressed
a quirk is necessary for this device to not inhibit scroll events.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
|
|
https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/512 disables
input smoothing for AES devices. However, some AES devices produce
segmented/wobbly curves without smoothing. This change introduces an
`AttrTabletSmoothing` boolean property, which overrides the default smoothing
behavior.
See #632
Signed-off-by: Quytelda Kahja <quytelda@tamalin.org>
|
|
Squashes compiler warnings about unused functions given this header is
included in multiple files.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|