Commit 94b7836456 ("filter: support accelerating high-resolution
scroll wheel events") introduced a regression where high-res scroll
wheel events were incorrectly normalized by DPI. Mice with non-default
DPI (e.g., Logitech G502 at 2400 DPI) had their scroll wheel speed
reduced by the DPI ratio (1000/2400), resulting in 2-3x slower
scrolling.
The "noop" filter functions were actually performing DPI normalization
or applying a constant acceleration factor, which is appropriate for
button scrolling but incorrect for scroll wheels that have their own
units.
Add a filter_scroll_type enum (CONTINOUS, WHEEL, FINGER to match the
public events) passed through the filter_scroll interface. Update all
filter implementations to skip acceleration and normalization for wheel
events while maintaining existing behavior for button scrolling and
touchpad scrolling.
The custom acceleration profile continues to accelerate high-res wheel
events as designed.
Fixes: 94b7836456 ("filter: support accelerating high-resolution scroll wheel events")
Closes: #1212
Signed-off-by: Yinon Burgansky <yinonburgansky@gmail.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1363>
Adds a dedicated scroll movement type to the custom acceleration profile.
Supported by physical mouse and touchpad.
Other profiles remain the same by using the same unaccelerated filter for the scroll filter.
Signed-off-by: Yinon Burgansky <51504-Yinon@users.noreply.gitlab.freedesktop.org>
Users that want a flat pointer acceleration want the input speed to
match 1:1 to the output speed, barring a fixed constant multiplier.
This will apply to things like button scrolling as well, so let's map
the constant accel function to the non-constant accel functions to the
speed setting applies to every movement.
This is applied to both the flat and the touchpad flat filter.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The filter vs const filter is supposed to be for accelerated vs
non-accelerated motion (e.g. pointer motion vs scrolling) - in both
cases the returned value is supposed to be in the same coordinate
system, just once with an extra accel factor applied.
This was broken in the flat and low-dpi profiles: in both of those the
accelerated filter does *not* normalize, it merely applies the fixed/adaptive factor.
The constant filter normalized however. The result was that on e.g. a
5000dpi mouse the constant motion was 5 times slower than the
accelerated motion, even with a factor of 1.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This also fixes a bug with the _noop function, because we casted to the wrong
struct the dpi value was garbage.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
