The custom acceleration profile allow the user to define custom
acceleration functions for each movement type per device, giving
full control over accelerations behavior at different speeds.
This commit introduces 2 movement types which corresponds to the
2 profiles currently in use by libinput.
regular filter is Motion type.
constant filter is Fallback type.
This allows possible expansion of new movement types for the
different devices.
The custom pointer acceleration profile gives the user full control over the
acceleration behavior at different speeds.
The user needs to provide a custom acceleration function f(x) where
the x-axis is the device speed and the y-axis is the pointer speed.
The user should take into account the native device dpi and screen dpi in
order to achieve the desired behavior/feel of the acceleration.
The custom acceleration function is defined using n points which are spaced
uniformly along the x-axis, starting from 0 and continuing in constant steps.
There by the points defining the custom function are:
(0 * step, f[0]), (1 * step, f[1]), ..., ((n-1) * step, f[n-1])
where f is a list of n unitless values defining the acceleration
factor for each velocity.
When a velocity value does not lie exactly on those points, a linear
interpolation of the two closest points will be calculated.
When a velocity value is greater than the max point defined, a linear
extrapolation of the two biggest points will be calculated.
Signed-off-by: Yinon Burgansky <51504-Yinon@users.noreply.gitlab.freedesktop.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously we restricted rotation to trackballs only and to multiples
of 90 degrees. Update rotation allow angles other than multiples of 90.
Also enable rotation on all mice. The only devices without rotation
are now pointing sticks.
Fixes#827
Signed-off-by: Lucas Zampieri <lzampier@redhat.com>
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>
A user was experiencing issues with their hand being recognized as
touch input above the stylus tip.
Since touch above the stylus should be rare, increase the touch
arbitration rectangle height by 50mm.
Fix: https://gitlab.freedesktop.org/libinput/libinput/-/issues/809
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
When compiling with Sparse enabled:
$ CC=cgcc meson builddir
Fix warnings about variables that should be made static.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Fix the warnings generated:
[232/243] Compiling C object libinput-test-suite.p/test_test-pad.c.o
../test/test-pad.c:211:3: warning: variable 'count' is uninitialized
when used here [-Wuninitialized]
count++;
^~~~~
../test/test-pad.c:261:3: warning: variable 'count' is uninitialized
when used here [-Wuninitialized]
count++;
^~~~~
When building with Clang v15 and without libwacom:
$ CC=clang CXX=clang++ meson builddir -Dlibwacom=false
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Fix the warning generated:
[129/243] Compiling C object libinput-test-suite.p/test_test-touchpad.c.o
../test/test-touchpad.c:2679:1: warning: unused
function 'touchpad_has_rotation' [-Wunused-function]
touchpad_has_rotation(struct libevdev *evdev)
^
When building with Clang v15 and without libwacom:
$ CC=clang CXX=clang++ meson builddir -Dlibwacom=false
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Fix warning building with Clang v15:
../test/test-pad.c:334:15: warning: variable 'expected_number'
set but not used [-Wunused-but-set-variable]
unsigned int expected_number = 0;
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
The escape key can be used to cancel a drag and drop action in some
desktop environments. However, it triggers disable-while-typing, ending
the drag and drop action rather than cancelling it.
Add it to the tp_key_ignore_for_dwt() set to avoid it.
Since I'm here, add the asterisk key as it is the only numpad key not
ignored by tp_key_ignore_for_dwt().
Fix: https://gitlab.freedesktop.org/libinput/libinput/-/issues/820 # [1]
Suggested-by: satrmb <10471-satrmb@users.noreply.gitlab.freedesktop.org>
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
The ck_assert_ptr_null() function is not available in the version of
the check library included in 20.04 LTS Focal (0.10.0).
Use ck_assert_ptr_eq() to avoid compilation errors.
Fixes: eeae8906db ("util: return the number of elements from strv_from_string")
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
When the libwacom build option is set to false the compiler throws
these warnings:
../udev/libinput-device-group.c:95:1: warning: ‘wacom_handle_ekr’ defined but not used [-Wunused-function]
95 | wacom_handle_ekr(struct udev_device *device,
| ^~~~~~~~~~~~~~~~
[205/237] Compiling C object 'libinput-test-suite@exe/test_test-tablet.c.o'.
../test/test-tablet.c:5440:1: warning: ‘verify_left_handed_touch_sequence’ defined but not used [-Wunused-function]
5440 | verify_left_handed_touch_sequence(struct litest_device *finger,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../test/test-tablet.c:5385:1: warning: ‘verify_left_handed_tablet_sequence’ defined but not used [-Wunused-function]
5385 | verify_left_handed_tablet_sequence(struct litest_device *tablet,
# | ^~~~~~~~~~~~~~~~
# | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Add the required guards to fix the warnings.
Fix#791.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
The `debounce_bounce_high_delay` and `debounce_spurious_trigger_high_delay`
tests are failing with annoying frequency in valgrind, but that is
entirely due to valgrind being too slow for the tight timing reqirements
of these tests. Skipping them in valgrind has next to no potential to hide
memory leaks because the code paths leading to success are also covered by
other tests which are less picky about timing, and the CI test suite run
without valgrind still tests for their success.
Signed-off-by: satrmb <10471-satrmb@users.noreply.gitlab.freedesktop.org>
These two tests were identical except for the WHEEL/HWHEEL
differentiator, let's make this into a ranged test instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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: 6bb02aaf30 ("High-resolution scroll wheel support")
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Tested-by: Peter Ganzhorn <peter.ganzhorn@gmail.com>
These tests gave us false positives for devices without a REL_WHEEL or
REL_HWHEEL because one of the helper functions papered over missing
events.
We have two tests here, one for horizontal, one for vertical but they
mixed WHEEL and HWHEEL in both tests. Fix this by splitting them
properly, so each test only checks that axis.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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 61bdc05fb0 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>
Because --filter-test does substring matching it's easier to have it
with a unique name rather than one that is a prefix of another.
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>
Certain tests that make use of verify_left_handed_touch_motion can fail
depending on how quick they are executed, specially when using Valgrind.
Instead of ignoring the hold end event, use the existing mechanism to
disable hold gestures where we are not interested in them.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
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>
Since cd4f2f32b5 ("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>
This device triggers a kernel bug in the InRange and Invert handling,
every time BTN_TOUCH is set the device also sets BTN_TOOL_PEN even when
we currently have the eraser in proximity.
Recording from https://github.com/linuxwacom/xf86-input-wacom/issues/186
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Depending on how quick the test suite runs we may get a hold end event
here. Let's silently ignore that one since we aren't interested in it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Add two helper functions that set/unset BTN_TOUCH together with the
specified axes and switch all tests over.
Devices can override the tip down/up sequence.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Don't use the litest wrapper context here, it changes log priority if
the test suite is run with --verbose, causing the test to fail.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
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>
Extract the logic in litest_assert_event_type to a generic function,
litest_assert_event_type_is_one_of, that takes a variable number of
expected event types.
Refactor, no functional changes.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
This way we can ensure that at least one device is available, and that
it is the device we want.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
meson uses MESON_TESTTHREADS to determine the number of parallel test
jobs. Since our main test suite cannot be run in parallel anyway, use
that same variable in litest to determine how many jobs we should fork
off.
In the CI pipeline, we can use FDO_CI_CONCURRENT to pass that down so we
don't end up running a billion jobs on a test runner.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
