https://bugs.kde.org/show_bug.cgi?id=358472
David Edmundson <k...@davidedmundson.co.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |CONFIRMED
--- Comment #23 from David Edmundson <k...@davidedmundson.co.uk> ---
This is a combo bug in both Qt's XCB backend and ScrollArea in QtQuickControls
scrolling has two modes, moving by n pixels or by n "ticks".
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.
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.
In QXcbConnection::xi2HandleScrollEvent scrollingDevice.verticalIncrement is 15
.
This matches what I see in xinput list which shows:
Class originated from: 11. Type: XIScrollClass
Scroll info for Valuator 2
type: 2 (horizontal)
increment: 15.000000
flags: 0x0
We then go into the
// We do not set "pixel" delta if it is only measured in ticks.
if (scrollingDevice.horizontalIncrement > 1)
rawDelta.setX(delta);
In most Qt code this isn't a problem. Either pixel delta is ignored or it looks
about right anyway
In QtQuickControls QtQuickWheelArea we have a huge bug; as we now have valid
pixelDelta we go into a different code path that ignores the user scrollspeed.
It then randomly divides things by 2 to match some OS X behaviour.
This is what leads to things being slow and corrupted fonts.
I'll probably have to close this as upstream once I file a bug report there.
--
You are receiving this mail because:
You are watching all bug changes.
