Bug 464592

Can confirm.

Is it related to this commit: https://invent.kde.org/plasma/kwin/-/commit/9cd52b4060d5db3c7b10340e78236b3c216567cb ?

The proximate cause is indeed that commit. The second order cause is that there's currently no good way for kwin to modify scroll speed in a way that affects the things it should and doesn't break things it shouldn't. Sometimes an application wants to scroll something for every "scroll wheel tick". For example, scrolling through a list of tabs. This is what the axis_discrete value is for. Take a look at the following events:

kwin_wayland dev, no deltav120 scroll factor patch, no scroll factor
    [2599589.845] wl_pointer@22.axis_source(0)
    [2599589.906] wl_pointer@22.axis_discrete(0, 1)
    [2599589.921] wl_pointer@22.axis(2369707, 0, 15.00000000)
    [2599589.935] wl_pointer@22.frame()
+max scroll factor
    [2647199.034] wl_pointer@22.axis_source(0)
    [2647199.120] wl_pointer@22.axis_discrete(0, 20)
    [2647199.147] wl_pointer@22.axis(2417316, 0, 300.00000000)
    [2647199.170] wl_pointer@22.frame()

kwin_wayland dev, deltaV120 scroll factor patch, no scroll factor
    [3170612.194] wl_pointer@22.axis_source(0)
    [3170612.266] wl_pointer@22.axis_discrete(0, 1)
    [3170612.281] wl_pointer@22.axis(2940729, 0, 15.00000000)
    [3170612.296] wl_pointer@22.frame()
+max scroll factor
    [3204697.284] wl_pointer@22.axis_source(0)
    [3204697.347] wl_pointer@22.axis_discrete(0, 1)
    [3204697.363] wl_pointer@22.axis(2974814, 0, 300.00000000)
    [3204697.378] wl_pointer@22.frame()

The axis event value is supposed to be the angle by which the scroll wheel moved, while the axis_discrete event value is supposed to be the number of scroll wheel "ticks" that it has moved by. kwin's implementation of adjustable scroll speed hinges on multiplying these values.

The problem is that if kwin_wayland sends an axis_discrete with a value of 20, that tells the client that the scroll wheel has moved 20 "ticks", which is incorrect. This would cause anything where you want to scroll just one "item" per tick of the wheel to scroll 20 times instead. So the patch makes it so the axis_discrete value is not multiplied. Only the axis value will be multiplied.

But Qt, and maybe other toolkits, don't provide a way for their applications to distinguish between the discrete event and the axis event. Qt in particular will ignore the axis event value if a discrete value is present. So kwin's choice is to either multiply the discrete event (which will break anything that relies on it), or not multiply it (which will prevent it from applying to toolkits that don't handle it properly).

We're currently looking at ways to solve this.

I see, thanks for the explanation. However, what is strange is that on my system, discrete scrolling was working fine previously, and now each tick of the wheel often scrolls two or three times (for instance when scrolling through the list of windows on the bottom panel).

I am using a Logitech M720 Triathlon mouse.

(In reply to legimet from comment #4)
> I see, thanks for the explanation. However, what is strange is that on my
> system, discrete scrolling was working fine previously, and now each tick of
> the wheel often scrolls two or three times (for instance when scrolling
> through the list of windows on the bottom panel).

Try opening 10 tabs in Konsole and scroll through them, does it happen there?

(In reply to John Brooks from comment #6)
> Try opening 10 tabs in Konsole and scroll through them, does it happen there?

Yes, it does, it scrolls through 3, 4, even sometimes 6 tabs at a time. Note that under X11 everything is normal.

Actually I was wrong, Konsole scrolls through more than one tab at a time regardless of whether I'm in X11 or Wayland, and the same is true of other KDE applications like Kate and Dolphin.

However, in X11 scrolling works as normal for the bottom panel, as well as some other applications that I tested, like GIMP and Enigma (a game, where you can scroll through your inventory). All of these have the bad scrolling behavior in Wayland.

Let's take the discussion of the extra scroll events to Bug 464776, as it's not related to the scrolling speed setting.

I'm also affected by this. Interestingly, scrolling with the ball on a trackball (by setting ScrollOnbuttondown true in qdbus) has been unaffected by this. Has been this intended too? GTK apps seem to be unaffected by this but I only tested firefox.

I'm also affected by this, I used the scroll_factor option mainly because it scrolls three items at once in Minecraft. Though the problem isn't there in Konsole.

Is it possible to revert the change responsible for this if a proper solution will take some time? Latest KDE version is basically unusable in it's current state because of it for me.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/3900

Git commit fec40b71631ed0e5104b92d53340764198d37c35 by Nate Graham.
Committed on 29/03/2023 at 15:55.
Pushed by ngraham into branch 'master'.

Revert "backends/libinput: don't multiply v120 value by scroll speed"

This reverts commit 9cd52b4060d5db3c7b10340e78236b3c216567cb.

This commit broke the adjustable scroll speed feature on Wayland. That
feature may not have been implemented in the most technically ideal way,
but simply breaking it and leaving the mouse KCM with UI control that
does nothing isn't great. Besides, there was always a simple way to
avoid any scroll-related regressions caused by this feature: reset the
scroll speed to its default value, which internally is a multiplier of 1
and exercises the same codepath that 9cd52b40 imposes on everyone.

We can come up with a better implementation for Plasma 6.
FIXED-IN: 5.27.4

M  +1    -1    src/backends/libinput/events.cpp

https://invent.kde.org/plasma/kwin/commit/fec40b71631ed0e5104b92d53340764198d37c35

Git commit 659cfcb4937f36e3084478afcd0ac2518d53b3cd by Nate Graham.
Committed on 29/03/2023 at 17:39.
Pushed by ngraham into branch 'Plasma/5.27'.

Revert "backends/libinput: don't multiply v120 value by scroll speed"

This reverts commit 9cd52b4060d5db3c7b10340e78236b3c216567cb.

This commit broke the adjustable scroll speed feature on Wayland. That
feature may not have been implemented in the most technically ideal way,
but simply breaking it and leaving the mouse KCM with UI control that
does nothing isn't great. Besides, there was always a simple way to
avoid any scroll-related regressions caused by this feature: reset the
scroll speed to its default value, which internally is a multiplier of 1
and exercises the same codepath that 9cd52b40 imposes on everyone.

We can come up with a better implementation for Plasma 6.
FIXED-IN: 5.27.4


(cherry picked from commit fec40b71631ed0e5104b92d53340764198d37c35)

M  +1    -1    src/backends/libinput/events.cpp

https://invent.kde.org/plasma/kwin/commit/659cfcb4937f36e3084478afcd0ac2518d53b3cd