SUMMARY I appreciate the effort on the MR made for adding autoscroll, but I can't deny it's pretty uncomfortable to have to hold press the middle-click to still scroll, the reason why many people use autoscroll is they don't want to be touching their wheel button. I understand that the original reason why it was implemented in such a way was because there is a lot of users using the middle button as a paste button, which is why I propose adding another setting to decide what the user prefers for autoscrolling.
This is unfortunately something that the Libinput driver itself would have to support.
It is already supported by libinput though: https://wayland.freedesktop.org/libinput/doc/latest/api/group__config.html#ga3bbcd5f1201289dc50f965ef46c4ddea
Oh OK, then I guess we can do it! Thanks for setting me right.
*** Bug 504013 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/9671
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/3909
Git commit 85900c7755924d3a7f067ced14ce25145512f1a5 by Vlad Zahorodnii, on behalf of Uriel Fontan. Committed on 03/09/2026 at 16:44. Pushed by vladz into branch 'master'. Implement locking for on-button scrolling Added support for a feature similar to auto-scroll on Windows For testing it should be used together with https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/3909 and enable the setting in `Mouse & Touchpad -> Mouse -> Choose the correct device you use as a mouse on device -> Scrolling -> Enable the toggle and then choose the tap radio button` M +2 -2 autotests/integration/test_helpers.cpp M +22 -0 autotests/libinput/mock_libinput.cpp M +2 -0 autotests/libinput/mock_libinput.h M +1 -1 src/backends/fakeinput/fakeinputbackend.cpp M +3 -0 src/backends/libinput/connection.cpp M +25 -0 src/backends/libinput/device.cpp M +20 -0 src/backends/libinput/device.h M +1 -1 src/backends/wayland/wayland_backend.cpp M +1 -0 src/backends/x11/x11_windowed_backend.cpp M +1 -1 src/core/inputdevice.h M +1 -0 src/input_event.h M +1 -1 src/plugins/buttonrebinds/buttonrebindsfilter.cpp M +6 -6 src/plugins/eis/eiscontext.cpp M +42 -1 src/pointer_input.cpp M +14 -1 src/pointer_input.h https://invent.kde.org/plasma/kwin/-/commit/85900c7755924d3a7f067ced14ce25145512f1a5
Git commit 16ebca0b9ef0daf0f7c8317cd71e5cb3edaa95f7 by Nate Graham, on behalf of Uriel Fontan. Committed on 03/09/2026 at 19:13. Pushed by ngraham into branch 'master'. kcms/mouse: Add UI to control on-button scroll locking Add a "tap to autoscroll" option which a lot of users that come from Windows use. Depends on https://invent.kde.org/plasma/kwin/-/merge_requests/9671 FIXED-IN: 6.8.0 M +7 -1 kcms/mouse/backends/kwin_wl/kwin_wl_device.cpp M +17 -0 kcms/mouse/backends/kwin_wl/kwin_wl_device.h M +8 -0 kcms/mouse/inputdevice.h M +46 -2 kcms/mouse/ui/main.qml https://invent.kde.org/plasma/plasma-desktop/-/commit/16ebca0b9ef0daf0f7c8317cd71e5cb3edaa95f7
Just a question, does this work EVERYWHERE or it only works on scrollable surfaces? Some games and programs use the scrollwheel/scroll click to do some actions, like Blender, Minecraft and etc. On Windows this only works on scrollable pages, tho it seems to be more related to the program rather than the system ability to do this type of scrolls. I imagine this can't be achieved with a global scroll system to the mouse like this is proposed here, and in the solution before this, just asking. It still a very nice feature that I'll probably enable
(In reply to Daniel (NIICKTCHUNS) from comment #10) > Just a question, does this work EVERYWHERE or it only works on scrollable > surfaces? Some games and programs use the scrollwheel/scroll click to do > some actions, like Blender, Minecraft and etc. On Windows this only works on > scrollable pages, tho it seems to be more related to the program rather than > the system ability to do this type of scrolls. Everywhere. It's an upstream libinput feature, and its main function is scroll wheel emulation for pointer device categories that typically do not have any (such as trackpoints/pointing sticks). As such it pretty much has to work in all the places where a scroll wheel could potentially do something, which is everywhere. With the pre-exising non-locking version, regular middle click works as normal, but you can't middle-click drag at all. With the new locking version, middle-click will always enter this mode (but you can do a regular middle-click by pressing the button twice, and this does allow you to middle-click drag this way). It's superficially similar, but quite distinct from Windows auto-scroll. You are right that to implement that kind of behavior, it's likely much easier on the application side (which knows whether the click is in a scrollable view and whether it's over anther thing that should receive middle clicks instead of entering this mode). Some applications, such as browsers, already implement this as an option. (And enabling this lock feature would interfere with that).
(In reply to cwo from comment #11) > It's superficially similar, but quite distinct from Windows auto-scroll. > You are right that to implement that kind of behavior, it's likely much > easier on the application side (which knows whether the click is in a > scrollable view and whether it's over anther thing that should receive > middle clicks instead of entering this mode). Some applications, such as > browsers, already implement this as an option. (And enabling this lock > feature would interfere with that). I been wanting to figure out what I can improve, there is methods of activation that people recommended like double clicking for lock instead of one click, or also hold and only when you drag it "latches" onto lock mode. I also been meaning to add support for constant scrolling after you move the mouse a little, like how autoscroll behaves in most software. I also mentioned in the MR or in the kwin chat (don't specifically remember) to add a spec on Wayland for compositors to know if an input was used or not as most frameworks already have that feature implemented on their event system. The other alternative is to add a new key on XDG Settings portal for enabling autoscroll on software that supports it.
Another idea I also had is maybe window rules? Maybe a preset for this setting so people can like easily add software they want this feature to work in or not work in
+1 for the window rules toggle. :) I actually already opened another issue regarding this: https://bugs.kde.org/show_bug.cgi?id=504010