After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 692666 - Scroll speed cannot be configured
Scroll speed cannot be configured
Status: RESOLVED NOTGNOME
Product: gnome-control-center
Classification: Core
Component: Mouse
3.14.x
Other All
: Normal normal
: ---
Assigned To: Control-Center Maintainers
Control-Center Maintainers
: 697404 757100 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-01-28 00:55 UTC by p.yorick
Modified: 2018-11-24 12:06 UTC
See Also:
GNOME target: ---
GNOME version: 3.13/3.14



Description p.yorick 2013-01-28 00:55:11 UTC
Fairly straightforward. This needs to be fixed. I have mice that scroll pages at the barest touch (and are therefore unusable without xinput hackery) and other mice that require four or five turns of the wheel to scroll down a paragraph (and are therefore equally as unusable).

This has been a problem in Gnome for *over a decade*. https://bugzilla.gnome.org/show_bug.cgi?id=89259

Somebody *please* just implement it.
Comment 1 Adam Niedling 2013-03-05 08:31:48 UTC
This bug is recently getting lots of attention at the downstream bug report:
https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/124440
Comment 2 Ondrej Holy 2013-04-11 12:45:00 UTC
*** Bug 697404 has been marked as a duplicate of this bug. ***
Comment 3 Teppo Turtiainen 2014-10-19 05:24:10 UTC
Confirmed with gnome-control-center 3.14.1 on Fedora 21.
Comment 4 Theodor van Nahl 2015-03-31 14:01:32 UTC
Confirmend with gnome-control-center 3.16. on Arch.

Is there a reason why this hasn't been implemented in gnome (e.g. conflicts with guidelines) or did just nobody implement this? I there is a chance to get a patch into upstream I would do some work in this regards.
Comment 5 André Klapper 2015-03-31 20:07:21 UTC
Silence means that nobody works on this. :) More info if you're interested to contribute code: https://wiki.gnome.org/Git/Developers
Comment 6 Bastien Nocera 2015-04-10 13:14:49 UTC
This needs implementing in libinput first if it's going to be added to the UI.
Comment 7 Bastien Nocera 2015-04-14 13:21:55 UTC
It doesn't actually need to be a configuration option, but it's a property of the hardware. You'll need to file a bug against systemd or libinput at bugzilla.freedesktop.org for the angle of the scroll wheel to be tagged properly.

See those articles for details:
http://who-t.blogspot.com.au/2015/01/providing-physical-movement-of-wheel.html
http://cgit.freedesktop.org/systemd/systemd/commit/?id=011c703495fb564a49dea44b424445241cd58634

Feel free to post the bug URL here for others to follow.
Comment 9 p.yorick 2015-08-26 17:40:03 UTC
Hardware support for 15 degrees v. 20 degrees is not the same thing as a user-configurable sensitivity multiplier and/or acceleration factor. KDE, Windows, and Mac OS all support this as an option.

Add another two years onto this being a basic, unsupported feature I guess.
Comment 10 André Klapper 2015-08-26 21:21:28 UTC
@steppres: For random offtopic operating system comments please use some forum or blog instead of GNOME Bugzilla. Thanks!
Comment 11 André Klapper 2015-10-27 10:50:07 UTC
*** Bug 757100 has been marked as a duplicate of this bug. ***
Comment 12 Claudius Ellsel 2016-09-23 11:24:06 UTC
To me it seems an UI specific issue, since other desktop enviroments (KDE as stated above) have this feature.

Also I don't think this can be considered as fixed since I don't think there is the "one" scroll speed that just needs to be set correctly in specific drivers.
This is the argument @steppres was making and he underlines this by stating examples of other operating systems. So I don't think this comment is offtopic.
Comment 13 Claudius Ellsel 2018-11-24 12:06:59 UTC
Unfortunately I thought this was all to be implemented inside the desktop environment itself for a long time.

But apparently this is really on the libinput side as @Bastien Nocera already mentioned in comment #6 and #7. So I created an issue on the bugtracker of libinput: https://gitlab.freedesktop.org/libinput/libinput/issues/185