This is a leftover from the Lua plugin branch where the question of
whether to have public plugins before or after internal plugins is a
valid one. We don't have public plugins here, so let's remove this
fixme.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1269>
Fixes a regression causing missing scroll events on devices where the
kernel only sets REL_WHEEL/REL_HWHEEL but not the corresponding
hires events. On those devices we would get the legacy axis events but
no longer the new ones.
The mouse wheel plugin will correctly emulate missing hires events
but it doesn't attach to devices where the hires bit is never set.
This plugin can be very simple - since we know we enabled the code on
this device we don't need to keep any extra state around. If our frame
handler is called for this device we want to add the hi-res events.
Theoretically this breaks if the device has only one hi-res axis enabled
but not the other one (i.e. REL_WHEEL_HI_RES but only REL_HWHEEL) but
that's too theoretical to worry about.
Closes#1156
Fixes: 31854a829a ("plugin: only register the wheel plugin on devices that have a wheel")
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1268>
For mice with multipliers 30/120 and 40/120 nothing would change
as both will still cross threshold only after 2nd event.
But for MX Master 3 (and maybe others) that makes scroll beginning
a bit responsive, without jumping straight to 64/120 or 72/120.
Now events being emitted at 16+16+16 or 24+24 without significant
side-effects ("twitching" when resting finger on the wheel,
sudden scroll events when pressing middle button, etc). See !1262 for
some background.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1267>
The MX Master 3 is difficult, its wheel events are all over the place
and heuristics are tricky to determine. The previous plugin behavior
was seemingly sufficient for the MX Master but not for other devices.
Restore the old behavior if the quirk is set for a device by adding a
fourth state ALWAYS_ACCUMULATE. In this state the min movement is never
updated from the original threshold, causing any wheel motion to
accumulate.
Ref: ca6b82841c ("plugin/wheel: tighten the wheel debouncing code")
Ref: bb05e0d1b5 ("plugin/wheel: don't accumulate for low HID resolution multipliers")
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1262>
Accumulating (and partially discarding) scroll wheel events serves to
debounce a scroll wheel and provide for more fluid scrolling where
scroll wheels can send events going in the wrong direction.
This is unlikely to happen on devices with low resolution multipliers
(i.e. where some significant physical movement by the wheel is required
to trigger events) so let's make it contingent on devices more likely to
have flaky wheels.
The magic threshold picked is 30 (HID resolution multiplier of 4) as a
guess. The resolution multiplier isn't accessible in userspace so we
have to heuristically get to it - typical interaction with a mouse will
have that value set within the first two, three scroll wheel events
though.
Closes#1150
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1261>
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>
No functional changes, all the actual interfaces now simply loop through
the frame instead of expecting the dispatcher to do so.
The mtdev code changed slightly since we can shortcut in the non-mtdev
case.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1245>
Touchpad devices are pointers too in libinput but they don't usually
have wheels. Let's check for REL_WHEEL in device_new *and* then again
for the actual pointer capability in device_added.
Fixes: d1800a76fe ("evdev: Handle scroll wheel with a plugin")
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1251>
The function name doesn't represent what the function really does.
Rename it and be consistent with the naming of other related functions
like wheel_set_scroll_timer() or wheel_cancel_scroll_timer().
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1241>
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>
