Add Touchpad Scroll Sensitivity Adjustment Feature

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.


This is such a needed Gnome feature!

The scroll speed for me is way too fast, even after a year of driving Linux daily I struggle to find it to be the ‘just right’ speed and adapt to it.


+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)


FWIW Sway implements this with thei scroll_factor config value, so the Sway devs think that it can/should be controlled at the compositor level.

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.


Unfortunately I’m going to follow suit with the above; this is such a fundamental usability issue that I’m probably going to have to switch to Plasma :confused:


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.

Thanks and apologies if none of this makes sense!

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:

Give 'em a go.

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.

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?

Yes please, this would be very good to have alongside the existing touchpad configuration

One of the most needed fixes / enhancements (both really)

If it could show a discrete number so the same setting can be replicated, like plasma, I would like it, even more if other adjustments did this too.

Could you detail what you did for this change, I’d be interested to see and test myself - thanks.

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.

1 Like

Tested and yes, it works. However, it has the unintended impact of making overscroll events (e.g. two finger back in Firefox) harder to trigger.

This seems to work in a similar way to the popular hack which overrides the compositor