This patch contains a new button invoked scrolling mode optimized for
use with 5 button mice. The preferred invokation button is the thumb
button, BTN_SIDE in evdev parlance. The initial direction of motion of
the mouse following press of the invoking button sets the scroll axis
and the sign of the subsequent scroll reports. Once set the axis and sign
of the scroll reports can only be changed by releasing and re-pressing
the invocation button. This scheme allows for arbitrarily long scroll
distances without lifting and replacing the mouse.
Only one axis is active for scrolling at a time. The preferred scroll
motion is circular, but any type of mouse motion is acceptable. The
distance scrolled is proportional to the manhattan distance moved by the
mouse. The dynamic range is expanded non-linearly based on movement
velocity such that the +-2^8 input range of mouse motion reports is
expanded to a +-2^16 range of scroll reports. The scheme takes maximum
advantage of the precision of the mouse, both arbitrarily slow and quite
fast scrolling are accommodated. The performance of the mode is such that
the scroll thumb is only needed for reference, it need never be "touched".
The mode is optimized for y axis use. The y axis is preferred in that axis
determination happens more easily for the y axis than for the x axis. This
is accomplished by creating a wider movement cone for y axis selection
than for x axis selection. Also, x axis selection can only begin following
a delay, now 250ms, from button press, whereas y axis selection is
immediate with as little dead/wasted movement as possible. The reason
for this asymmetry is personal. I find that when I am reflexively using
the mode I may move the mouse more to the left than I am intending,
particularly while I am simultaneously pressing the button and starting
motion. This behavior can result in x axis selection when y axis is
intended. Since I almost never scroll the x axis, I solved the problem
by heavily preferring the y axis. The more deliberate criteria for
selecting the x axis do not bother me at all. Of course I could have
defeated x axis selection entirely, but after significant use of the mode
I find the current setup to be almost foolproof for the y axis while
still allowing x selection without using up another button.
The mode is optimized for the internet browsing use case, following
hyperlinks and scrolling the resulting pages. Care is taken to assure
that the user is not confused by overloading the scroll modal button
with any other action. Once the new mode is assigned to a button,
that button cannot be used for any other purpose. Therefore, those that
are used to using mouse buttons 4 and 5 for their historical design use,
browsing forward and backward, may not initially take to the new mode.
However, patience might be rewarded sooner than one would think. At least
for some, the new mode easily becomes intuitive and automatic. And since
scrolling is performed far more frequently on modern systems than browsing
forward and backward, the increased efficiency of entering the scrolling
mode more than pays for the loss of button browsing behavior.
I've not before submitted code to the libinput project. Therefore I have
limited the changes to a single source file, evdev.c. Also, I have
conditioned the submitted changes so that the new mode is only operational
on devices that have the udev environment variable LIBINPUT_SIGNED_SCROLL
defined with a value of "1". An example udev rule to add such an
environment variable to a Microsoft 5-Button Mouse with IntelliEye follows:
ACTION=="add|change", KERNEL=="event[0-9]*", ENV{ID_VENDOR_ID}=="045e", \
ENV{ID_MODEL_ID}=="0039", ENV{LIBINPUT_SIGNED_SCROLL}="1"
I don't really know how to go about getting this change incorporated into
the libinput project. I've attempted to make the change in such a way as
to not interfere with any existing functionality. Further, I've made the
new functionality available only via the above not easily discoverable
incantation. In this way I'm hoping to get the change incorporated into
the main project so that others can somewhat easily try out the new mode.
Once people are comfortable that the new mode doesn't break anything, the
next step would be to make it more publicly usable via changes further
libinput changes plus changes to xorg-xf86-input-libinput and/or the
similar? wayland input driver.
Signed-off-by: Paul Ausbeck <paula@alumni.cse.ucsc.edu>
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>
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>
Later versions of this same model seem to have a different ALPS touchpad
and don't need the pressure settings. Narrow down this match so we only
apply to the one from the actual bug report in #565.
Fixes#676
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
When the kernel doesn't support a touchpad, the device is handled as a
generic mouse named "ImPS/2 Generic Wheel Mouse".
Taps are handled as button clicks and the button debouncing code makes
it difficult to double click.
Add a quirk to disable button debouncing for this devices.
Fix https://gitlab.freedesktop.org/libinput/libinput/-/issues/656
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
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>
Set multiplier for T470 to 0.4, same as for T480.
Trackpoint behavior on T470 was good before 1.9.0 (more precisely,
before the commit 87b568) when a new trackpoint acceleration algorithm
was introduced instead of the traditional linear filter. Since then
it is too sensitive and seems impossible to fine-tune using hw settings
or libinput accel speed setting.
With multiplier set to 0.4 it is as good (or better) as in 1.8.4.
Sensitivity feels the same as in 1.8.4 with the same hw settings for
speed and sensitivity.
Signed-off-by: Dmitry Maluka <dmitrymaluka@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>
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>
Starting with meson v0.49.0, the "/" operator can be used instead of
join_paths.
Update meson to v0.49.0 and remove all calls to join_paths.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Update GTK to version 4 on Fedora, Arch and Alpine Linux.
Not updating Debian and FreeBSD because the package is not available yet
and Ubuntu because it is not available on 20.10.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Move the code used to pace the different UI elements to its own
function.
Refactor, no functional changes.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
This does little other than drag in a whole bunch of dependencies. The
libinput documentation is designed to be consumed online, so there's no
need building it on every machine.
We leave the dependencies installed in the images because it's a lot
easier to remove them and test if the build still works than adding them
and dragging in every updated package since we built the image.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add a section in the contributing documentation with common pipeline
errors and how to fix them and point to this page when the CI fails.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
