Bug 1220101

Sorry, slightly poor phrasing there: by "wheel click", I mean the internal clicks as it scrolls, not actually clicking it as a middle-click.

In my case, it's an issue between xorg-x11-drv-libinput and Qt5, but I don't know which one is really to blame.

With xorg-x11-drv-libinput, a mouse with a scroll wheel will report :
~ xinput list 9
...
                Class originated from: 9. Type: XIValuatorClass
                Detail for Valuator 3:
                  Label: Rel Vert Scroll
                  Range: -1.000000 - -1.000000
                  Resolution: 0 units/m
                  Mode: relative
...
                Class originated from: 9. Type: XIScrollClass
                Scroll info for Valuator 3
                  type: 1 (vertical)
                  increment: 15.000000
                  flags: 0x0
...

The increment is 15, instead of -1 with xorg-x11-drv-evdev.

In QXcbConnection::xi2HandleScrollEvent, Qt5 set rawDelta (which will end up in QWheelEvent::pixelDelta()) when scrollingDevice.verticalIncrement > 1.

Starting from kf5-ktexteditor 5.7.0, QWheelEvent::pixelDelta() is used when available instead of QWheelEvent::angleDelta() * QApplication::wheelScrollLines() / 120.

=> "mouse wheel scrolls by" setting is ignored since kate prefers using QWheelEvent::pixelDelta() (good for touchpad edge scrolling for example). IMHO it shouldn't be set for mouse wheels, but xorg-x11-drv-libinput broke the "scrollingDevice.verticalIncrement > 1" test done in Qt5.

I don't know how this issue should be fixed :
 - set driver_data->scroll.vdist/hdist to 1 in xorg-x11-drv-libinput to match xorg-x11-drv-evdev ?
 - find a better way to replace the "scrollingDevice.verticalIncrement > 1" test in Qt5 ?
 - add a mouse wheel speed setting to xorg-x11-drv-libinput (for example to report a motion of 3*increment), which would replace the KDE/Qt setting ?

the increment meaning is fairly well defined:
      increment:
        The valuator delta equivalent to one positive unit of scrolling.

http://cgit.freedesktop.org/xorg/proto/inputproto/tree/specs/XI2proto.txt#n937

evdev sends the increment to -1 and sends out a value of -1 for a mouse wheel down, the xorg libinput driver sets the increment to 15 and then sends out a value of 15 - either way should result in the same amount of scroll units.
note that libinput does the direction flipping too, a mouse wheel is inverse to what you'd expect.

(In reply to Loïc Yhuel from comment #2)
> I don't know how this issue should be fixed :
>  - set driver_data->scroll.vdist/hdist to 1 in xorg-x11-drv-libinput to
> match xorg-x11-drv-evdev ?

not really a good idea tbh, it would prevent smooth scrolling from button-based scrolling which we offer for all mice because we can't send fractions of the scroll increment anymore.
http://wayland.freedesktop.org/libinput/doc/latest/scrolling.html

>  - find a better way to replace the "scrollingDevice.verticalIncrement > 1"
> test in Qt5 ?

yeah, that'd be my goto here. you could check the XI type from XListInputDevices() for XI_TOUCHPAD and toggle the behaviour based on that. The source of the problem is that libinput does the information of whether something is a wheel vs other scroll methods but we don't have anything in the X protocol (yet) to handle this.

>  - add a mouse wheel speed setting to xorg-x11-drv-libinput (for example to
> report a motion of 3*increment), which would replace the KDE/Qt setting ?

definitely no to this one, it's not a setting that should belong in the driver.

a last option could be to add another axis to the device that designates wheel scrolling alone, but I'm not sure how many other clients that would break then.

(In reply to Peter Hutterer from comment #3)
> (In reply to Loïc Yhuel from comment #2)
> >  - find a better way to replace the "scrollingDevice.verticalIncrement > 1"
> > test in Qt5 ?
> 
> yeah, that'd be my goto here. you could check the XI type from
> XListInputDevices() for XI_TOUCHPAD and toggle the behaviour based on that.
Qt only uses XIQueryDevice, and does many tests to determine the device type (including name checks). But I think keeping the non-touch non-tablet devices would be ok.

Button-based scrolling would result in events with QWheelEvent::angleDelta() smaller than 120, which is fine, but they would be affected by QApplication::wheelScrollLines().
>
> 
> a last option could be to add another axis to the device that designates
> wheel scrolling alone, but I'm not sure how many other clients that would
> break then.
Qt only supports one vertical and one horizontal axis per device.
Instead of an axis, would it be possible to create two devices ? I hope all clients are able to handle for example a mouse at the same time as a touchpad.

creating multiple devices from within the X driver is a PITA, we do that in the wacom driver because we have no choice there and it's quite high maintenance.
besides, this would likely make things worse, you'd then have a device that has x/y axes that don't produce events and a scroll axis. this is likely to confuse other pieces of the stack.

If you thought scrolling in Kate acts funny, try scrolling in Qt4-based Konsole (or anything that uses the Qt4-based Konsole KPart, like Yakuake).
Instead of scrolling, it appears to send arrow up and arrow down commands, i.e. browsing the command history.

(In reply to Markus S. from comment #6)

For me, scrolling on Yakuake works fine. So does Firefox, Thunderbird, KDevelop 4 and even Qt Creator (which is compiled against Qt 5.4.1).

I have problems with slow scrolling on KWrite, Kate, the desktop notes widget etc.

Is it possible that this is related to libinput? See https://bugs.kde.org/show_bug.cgi?id=355410

Is it possible that this is related to libinput and QML? See https://bugs.kde.org/show_bug.cgi?id=355410

that bug is relevant for any qml-related cases (which doesn't apply to kate/kwrite)

With the current versions, scrolling seems to be fine with KWrite & Kate. The mouse setting in system settings seems to be honoured.

For me, the slow scrolling affects only the desktop notes widget now.

Still a problem in F23 for widgets such as the kickoff menus and the software updates applet.

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

<nod>, still an issue though no real need to track downstream specifically, plenty of upstream bugs open tracking this (in general).

https://bugs.mageia.org/show_bug.cgi?id=19362
Bug 19362 - Mousewheel scrolling inside dolphin is very small at all settings in non-Plasma5-desktops 

https://bugs.kde.org/show_bug.cgi?id=369286
Bug 369286 - dolphin 16.08.1's Mousewheel scrolling is very small at all settings in non-Plasma5-desktops (regression from 16.04) 

https://bugs.kde.org/show_bug.cgi?id=358080
 DUPLICATE of bug 357618

https://bugs.kde.org/show_bug.cgi?id=357618
Bug 357618 - scrolling with xf86-input-libinput is unusable slow - only in dolphin 

https://bugs.kde.org/show_bug.cgi?id=365968
Bug 365968 - scrolling is unusable slow with libinput in dolphin places and folders panel 

https://bugs.kde.org/show_bug.cgi?id=355410
Bug 355410 - the scroll speed of QML scroll area is too slow with Libinput 


HOW MANY BUGS DOES THIS ISSUE HAVE TO MULTIPLY INTO BEFORE IT IS FIXED?