Scrolling has two modes, moving by n pixels or by n "ticks" normally for trackpads and traditional scroll wheels respectively.
In QWheelEvent terms:
- pixelDelta and angleDelta
A libinput change has meant that Qt's detection of "is it a scroll wheel or not" is broken.
If I put debug in QXcbConnection::xi2HandleScrollEvent I can see my scrollingDevice.verticalIncrement is 15 .
We then go into the
// We do not set "pixel" delta if it is only measured in ticks.
if (scrollingDevice.horizontalIncrement > 1)
This matches what I see in xinput list which shows:
Class originated from: 11. Type: XIScrollClass
Scroll info for Valuator 2
type: 2 (horizontal)
So QXcbConnection has the "right" value, but now that check doesn't work. I think libinput seems to trying to artificially say how far things should scroll at an input level rather than it being up to the application.
Though this is the root cause of the breakage, it is only a minor problem except in one place.
In QtQuickControls QtQuickWheelArea as we now have valid pixelDelta we go into a different code path that ignores the user scrollspeed. It then also randomly divides things by 2 to match some OS X trackpad behaviour. See comment on the static pixelDeltaAdjustment.
Instead of the scroll moving content at the correct rate of 60px (15x user set scrollSpeed) per tick, we only move 7.5 (15/2) pixels. This leads to very slow scrolling with bug reports downstream (KDE) and in some cases text corruption as it's not pixel aligned anymore.
To see the bug in action run ListPage.qml in QtQuickControls example with a proper mouse wheel.