Description: The GNOME Control Center’s Mouse & Touchpad settings currently allow users to adjust the speed of the touchpad but do not provide an option to adjust the scroll sensitivity. This feature request aims to introduce a touchpad scroll sensitivity adjustment option. This will enhance user experience by allowing finer control over how much content scrolls with each swipe on the touchpad. It’s particularly beneficial for users who deal with long documents or web pages and need more precise control over scrolling.
Use Case: Many users find the default scroll sensitivity either too fast or too slow, and the lack of an adjustment feature can lead to a less efficient and more frustrating experience. Providing this feature will align GNOME with other operating systems and desktop environments that already offer this capability.
Proposed Mockups:
-A slider below the “Touchpad Speed” slider in the Mouse & Touchpad settings panel.
-The slider should be labeled “Touchpad Scroll Sensitivity” with a range from “Slow” to “Fast” from left to right respectively.
-The slider can look just like the “Touchpad speed” slider.
Design Tasks Create UI mockups for the new scroll sensitivity slider. Design the slider to fit seamlessly with the existing GNOME Control Center aesthetics. Ensure accessibility and localization considerations are met in the design.
Development Tasks Implement the new slider in the GNOME Control Center’s Mouse & Touchpad panel. Add a new GSettings key for touchpad scroll sensitivity. Bind the new slider to the GSettings key. Ensure the setting communicates correctly with the underlying system, possibly requiring coordination with the touchpad driver (like libinput). Test across different GNOME versions and touchpad hardware.
QA Tasks Verify that the slider correctly adjusts the scroll sensitivity. Ensure no regressions in the Mouse & Touchpad settings panel. Test for both functionality and UI consistency across various GNOME themes. Validate that the feature works with different languages and respects accessibility standards.
+1, this is important and I’d like to provide some info on a deep dive I did + links regarding why this hasn’t been implemented yet.
This issue was submitted to libinput requesting scroll speed configuration, and it was noted by one of the maintainers that this was not the place to request it, and rather it should be in the compositor or toolkits, mainly due to complex responses like kinetic scrolling being content-aware responses, which libinput can’t do since it doesn’t know the context the input is being used in.
This GTK issue requesting a flag be made in GTK for adjusting scroll speed, and a response from one of its maintainers Emanuelle Bassi, who says this is something libinput needs to do, tl;dr not a toolkit issue.
Basically, everyone disagrees on where this kind of thing should be implemented. My $0.02 is that libinput is too low-level for it to be implemented there, and this comment by the maintainer Support setting scroll speed (#185) · Issues · libinput / libinput · GitLab explains why in a clear manner. The question of whether it will be implemented in GNOME is two-fold:
a) Whether someone will come and implement the feature
b) Whether GNOME will even accept the feature in the first place (GNOME can be resistant to change if they believe strongly that it is not their place to implement the change, rather another project’s responsibility)
EDIT: Relevant MR as this is one implementation of scroll speed settings circa 1 year ago:
gtk!4672 (I can’t provide the link as I am a new user and the forum limits me to 2 links per post)
As Ryan mentioned, there is still some work down the stack to be made for us to present the feature in Settings. But I (wearing my maintainer hat) want to state that this is a feature under my radar and I’m open to add it if the APIs are there.
Bumping this. Would pay money for this right now, my current laptop scroll speed is horrible. Really leaves much to be desired for the touchpad after switching from my Macbook touchpad which was perfect. Gnome gestures really made touchpad incredible and helped bridge that gap but this is the final piece for me imo
+1, as the overall situation for touchpad gestures has improved for the desktop and third party applications, one of the only areas I find lacking is that the scroll speed is not unified when jumping from an application like GNOME’s text editor to either Firefox or Chrome, the scroll speed varies drastically. Although it’s been a couple of years since I migrated, I do find myself yearning for the Mac trackpad experience on GNOME (scroll sensitivity and acceleration curve). With Wayland being the bigger and almost sole focus these days hopefully this feature ends up landing soon.
Yes, please! Touchpad scrolling on Wayland/GNOME is at times almost unusable in web browsers on laptops with high dpi screens. I have seen posts saying ‘cannot be done’, ‘will not be done’, etc. KDE managed to accomplish this in Plasma 5 on Wayland. GNOME naturally fits the way I like to work. But I have switched to KDE over this single issue. So sad.
I’m new here, and just trying to figure out how this all works, so please excuse me if I say something very incorrect.
To my understanding, Mutter is currently handling the scroll events (via clutter_event_get_scroll_delta in clutter/clutter-event.c. Would it not make sense if mutter handled this? Or, given gnome-shell is a plugin for mutter, can it not override the default mutter scroll event handler with this functionality?
Side question, can mutter load multiple plugins, or is it restricted to one at a time?
I’ve built mutter with a very simple hack into clutter-events.c where I multiply the delta with a float and it’s behaving exactly how I want it to, but it feels very wrong like that. I was thinking about adding a gsetting that could be tweaked at runtime, but it feels this should be hosted under org.gnome.desktop.peripherals.touchpad instead.
I add my support to this feature, it’s been annoying me to no end since I got an Apple Magic Trackpad 2 to use on Linux. The hardware is great, but scrolls way too fast on GNOME.
Firefox is pretty much unusable out of the box, but I’ve been using these settings for a while now, and they feel pretty good and what one would expect coming from macOS or iOS:
I’ve been reading about this and gotten a bit confused
EDIT: seems like this issue is DPI/scaling dependent. I’m on a 4k screen at 2x scaling, so you might have to tweak those values for your system
This sounds like a bug report, doesn’t it? Gnome is reporting different scroll values to applications depending on the screen DPI? Or is it the touchpad resolution?
Scrolling on my laptop is way too fast, but it’s not just my opinion. I’ve asked family members, they all say it’s too fast to be usable. Given that it’s not an opinion, maybe it shouldn’t be a preference. It sounds like an “unbreak my application please” button.
Maybe these problems should be solved with libinput device quirks?
In clutter_event_get_scroll_delta, I changed event->scroll.delta_x to event->scroll.delta_x * 0.2, and identically for _y and rebuilt mutter from source. The only effect from this which I experienced was slowing down the touchpad scrolling. Mouse scrolling was unaffected, so was pointer move speed - hence my guess that this function handles the touchpad scrolling only.
You can set mousewheel.default.delta_multiplier_x and y separately in firefox about:config to increase the x sensitivity, which makes the horizontal gestures easier to activate;
after slight experimenting, the above fix does not increase the gesture sensitivity.
Instead, just fix the touchpad sensitivity within firefox with the aforementioned option instead. However, you will be stuck with the same extreme scroll behavior in anywhere that is not firefox.
although it makes horizontal scrolling near impossible to use if the x and y values are not similar… Perhaps there is another configuration option to adjust the overscroll gesture sensitivity?
rant
quite disappointing that this option has not been added for at least 3 whole years (the reddit thread for this feature dates back to 2021).
Ryan documents in the 2nd reply, where we can see that the devs for the application toolkit and libinput both says that touchpad scroll sensitivity should not be implemented at their level.
Which then leaves the application, the wm/de/compositor, the kernel, and firmware level.
For the application layer, I believe it is definitely not the right place (even though the workaround for firefox listed above resides here) since we can’t reasonably expect every single developer implements this in every single app; and that’s without taking into account apps that are no longer maintained.
For the firmware level, again I believe it is not suitable to be implemented there given the majority of users probably don’t know how to or don’t want to dump, edit, and flash their firmware for the touchpad if it was even possible in the first place. Furthermore, laptop/touchpad manufacturers probably won’t care about this anyway since Windows handles it.
Which then leaves the kernel and the wm/de/compositor. With the argument from Peter(the libinput dev) saying
The second component is a UI issue and must be handled by toolkit, i.e. GTK/Qt/… Any configuration for scroll speed would have to be set there. This is what Windows does too…
Adjusting >scroll.delta_x * 0.2 in clutter does work at reducing scroll speed to an acceptable level across all applications. This to me indicates that it is the correct place to manage scroll speed. Instead of a fixed float this should be set from a slider in the touchpad settings allowing scroll speed to be increased / decreased depending on user preference
This leaves the problems of overscroll events and two finger side scrolls being used for page changes (e.g. gnome app grid).
I suggest a new two finger side swipe gesture is added that only triggers once a velocity threshold is crossed. This allows configurable two finger scroll speed but maintains the ability to trigger gesture cases.
