The previous approach had a fixed threshold of 60 (half a detent)
below which scroll events were ignored. Reduce this threshold to have a
threshold of one device-specific delta. That threshold adjusts over time
to the device's individual minimum delta so after a few scroll event it
should settle on the lowest value possible.
The result is that fine-grained scrolling is possible on those devices
and only the very first scroll event is held back/swallowed, two events
in the same direction release scrolling.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1258>
When the kernel inserts a repeat frame it does that with EV_KEY code
value of 2 and the frame itself is a SYN_REPORT with value 1. Nothing in
libinput wants those repeat values, so let's discard them here before
anything tries to process them.
This inserted frame causes bugs on touchpads with EV_REP (rare enough)
because while the key event itself is dropped, the timestamp of the
frame still causes the next real frame's delta time to shorten,
resulting in wrong acceleration values.
Closes#1149
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1255>
mtdev is used only for MT Protocol A device of which there are quite
few. But that protocol is also a perfect example for event frames in ->
different event frame out so let's move this into the plugin pipeline.
Because the plugin doesn't really have full access to the device's
internals we set up mtdev base on the libevdev information rather than
just handing it the fd and letting it extract the right info.
A minor functionality change: previously mtdev-backed devices returned
zero on libinput_device_touch_get_touch_count(). Now it is hardcoded to
10 - the number of callers that care about this is likely near zero.
Because it's now neatly factored out into a plugin we can also make
mtdev no longer a strict requirement.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1245>
We have one test device that only has a horizontal scroll wheel but not
a vertical one, causing these tests to run unexpectedly.
One test needs both enabled (not strictly so but let's not bother) and
the other one only needs the vertical wheel.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1251>
This device was added before high-res scroll events existing in the
kernel and it's used in a test to verify that a device that has
ABS_MT_POSITION_X but not _Y doesn't get automatically ignored.
Said test (device_quirks_no_abs_mt_y) uses a wheel event to verify that
we do get events from this device.
Since then we've long had kernels that support hi-res scrolling and the
kernel takes care of those events for us. So let's update the device
description and the events we send to include the high-resolution
events. That doesn't change the validity of the test but stops it from
becoming a false positive.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1251>
It's too much effort fighting clang-format for these snippets which
all don't really do much anyway but are important to be read easily.
Let's categorically disable all formatting in the test collections and
move on.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1246>
The use of the bug log handler should be replaced with the captured logs
now but meanwhile: don't abort if we're running in --verbose mode and
something prints a debug message before our expected bug error message.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1250>
The custom implementation of the send-events mode for tablet pads does
not actually suspend and resume the device, so events continue to be
sent despite the device being theoretically disabled. Fix this by
removing the custom send-events implementation in favor of
evdev_dispatch's implementation.
Also add a simple test to ensure the send-events mode works.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1238>
Previously we used uint32_t for bitmasks but having a custom type means
we're less likely to confuse an int value with a mask type.
Two types of API here, the u32 api for passing in masks and a bit API
for passing in single bits.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1218>
In these tests we have a secondary context but didn't call
libinput_dispatch() regularly so we're guaranteed to hit timeout errors
on the secondary context for any event sequence longer than e.g. our
hold gesture timeout.
litest_touch_move_to() waits 10ms between movements and calls
libinput_dispatch() but obviously not for the secondary context so we
need to do this manually.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1221>
In addition to the evdev_frame this struct is what contains our actual
events instead of a struct input_event. The goal of this is twofold:
slightly better memory usage per frame since we can skip the timestamp
and refer to the evdev frame's timestamp only. This also improves
handling a frame since we no longer need to care about updating
all events when the timestamp changes during appending events.
Secondly it merges the evdev type + code into a single "usage"
(term obviously and shamelessly stolen from HID). Those usages
are the same as the code names but with an extra EVDEV_ prepended,
i.e. EV_SYN / SYN_REPORT becomes EVDEV_SYN_REPORT.
And they are wrapped in a newtype so passing it around provides
some typesafety.
This only switches one part of the processing over, the dispatch
interfaces still use a struct input_event
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1215>
The kernel only ever gives us a frame of events in one go (it flushes on
SYN_REPORT). We then need to look at that frame as a single state change
(keyboards excepted for historical reasons) so let's push this into a
proper struct we can pass around.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1215>
