GNOME Bugzilla – Bug 674716
New "Smooth Scroll" does not respect .Xmodmap settings
Last modified: 2017-10-16 11:02:57 UTC
Since I upgraded to Gnome 3.4.1 (Archlinux, [extra]), core gnome apps no longer respect mouse buttons indications from ~/.Xmodmap. I created such a file a while ago to reverse scroll directions (see apple's "natural scrolling, ie touchpad scrolls like your phone : move your finger up, to move the page up, ie scroll down). Since .Xmodmap is not respected in gnome core apps (gedit, nautilus, …), I have a "traditionnal" scrolling in those, but reverse scrolling direction in other apps (firefox, libreoffice). That's an obvious bug, and having to go up once and then down in another app to achieve the same thing is a pain. I think this is due to "smooth scrolling" stuff in Gnome 3.4(.1), which may not match .Xmodmap, and so have hard-coded directions. To sum up, .Xmodmap is not respected and in certain cases, it can lead to major contradictions about how your mouse "works". Looks like I'm not the only one having this issue : https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/951123 Moreover, I think that "natural"/reverse scrolling is quite a cool (xorg) feature, and since Mac OS X is now using is by default, Mac users will be used to that, and may want reverse scrolling on gnome as well. I saw on a launchpad bug report that KDE has a setting to reverse scroll directions, and that would be welcome in Gnome. PS: I hope my bug report is OK, since it's my 1st one for gnome.
Also applies to settings set with "xinput set-button-map {idnum} {order}" (as in http://n00bsys0p.wordpress.com/2011/07/26/reverse-xorg-scrolling-in-linux-natural-scrolling/ )
Both .Xmodmap as well as the xinput set-button-map approach suffer from the 'here's a cool snipplet I found on the internet' problem - it is almost impossible to provide a working, consistent experience while at the same time allowing users to poke at random, deeply internal details of the inner workings of X. What these approaches do is to switch the legacy non-smooth scrolling (which traditionally works via buttons 4 and 5) to 'natural' mode. This does not affect the smooth scrolling that we are using with xi2.2 now. So, basically, 'natural scrolling' is unsupported until a checkbox for it appears in the mouse panel, I fear. Of course, you can perhaps figure out the new cool snipplet to tweak another internal detail to get this working with xi2.2 until we have that checkbox. I don't know the trick myself...
*** Bug 675047 has been marked as a duplicate of this bug. ***
See http://who-t.blogspot.com.au/2011/09/natural-scrolling-in-synaptics-driver.html
So, the command to play around with for xi2.2 is xinput set-prop <deviceid> "Synaptics Scrolling Distance" -<vert> -<horiz> to find good values for vert and horiz, look at the current values with xinput list-props <deviceid> Note that this only works with the synaptics driver currently, and only with version 1.6 (or 1.5.99.something). Also note that the interia calculation in the driver seems to be broken for negative deltas, so you'll have to set "Synaptics Coasting Speed" to 0 0 for now, or else you'll get 'infinite scrolling'.
What do we need to do to get that issue confirmed?
(In reply to comment #5) > Also note that the interia calculation in the driver seems to be broken for > negative deltas, so you'll have to set "Synaptics Coasting Speed" to 0 0 for > now, or else you'll get 'infinite scrolling'. Fixed in synaptics 1.6.2 (In reply to comment #6) > What do we need to do to get that issue confirmed? see comment #2?
*** Bug 688136 has been marked as a duplicate of this bug. ***
Ubuntu 12.04 users (and possibly others) see here: http://andym3.wordpress.com/2012/05/27/fixing-natural-scrolling-in-ubuntu-12-04/ The trick is that after using xinput to set the "Synaptics Scrolling Distance" property, nautilus needs to restart.
@thejohnnybrown : unfortunately that only works if you are using a touchpad (probably only a synaptics one?) and doesn't fix the mouse wheel on a mouse
Since this is still listed as UNCONFIRMED and hasn't had a comment in 8 months... I have this problem on Ubuntu 13.04 and Gnome Shell 3.6.3.1. I am on a desktop with a mouse not a touchpad and I want the mousewheel to use the "natural scrolling" (hey, I'm not thrilled either but if Apple says we're all gonna scroll that way then face it, we're all going there eventually). The .Xmodmap hack doesn't work for Nautilus or Gedit -- though as Mattias points out, that's probably never going to change because those apps have moved on to a newer mouse control system, and other apps will probably follow. Sooo... does anybody know if there's even a feature request anywhere to get an actual non-hacky setting for this?
Any chance to get this fixed? If I don’t want to resort to the ugly hack of setting negative scroll distances in synaptics, I end up with having natural scrolling in GTK2 and Qt applications, but traditional scrolling in GTK3 applications. That really drives me mad. Also note there’s a separate bug report in Ubuntu’s Launchpad: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/966237
there isn't anything in GTK to be "fixed": GTK uses XInput 2.x for implementing smooth scrolling, as it should. xmodmap does not cover that, and there isn't anything that GTK can do about that. gnome-settings-daemon's does exactly the same dance of setting a negative scroll distance on touchpads exposing the "Synaptics Scrolling Distance" atom, by monitoring the natural-scroll key of the org.gnome.settings-daemon.peripherals.touchpad - which is exposed in a check box in the Mouse & Touchpad control panel of gnome-control-center, i.e. the "a checkbox for it [...] in the mouse panel" to which Matthias was referring to. if you want to have have the same "natural scroll" for pointers with a scroll wheel then the right place to for this bug is in the gnome-control-center product. if you're not using GNOME, gnome-settings-daemon, or gnome-control-center, but you are using an equivalent environment (e.g. KDE, XFCE, etc) then you should open a bug for those, so that they implement the natural scrolling in the terms you want them. if you're not using GNOME, gnome-settings-daemon, or gnome-control-center, or any of the above environments (e.g. you're using something like IceWM, fvwm, fluxbox, etc.) and you want to have natural scrolling on both pointer devices with a scroll wheel *and* on touchpads, then you need to use xmodmap to modify the button mapping for the former, and the synaptics scroll distances for the latter. this will ensure that all X11 clients behave consistently, as they all get the same data. I'm going to close this bug, but feel free to re-open it if you fall under the "using GNOME" category and you find that toggling the switch in the control center does not work, or if you have a pointer device with a scroll wheel and you want the natural-scroll settings key to apply to that (in which case, when you re-open the bug, also re-assign it to the gnome-control-center product).
I am using GNOME and I have a mouse with a scroll wheel. I don't see any switch to toggle in the gnome control center. I understand a "fix" is not what we're looking for, but I would like to see a feature request to add support for natural scrolling with a mousewheel in GNOME. Is there such a thing and if not where can I add it?
I would reopen this case but I can't seem to figure out how to do that either, errrg....
Ahh, after rereading ebassi's 3rd para I found this bug report for a mousewheel natural scrolling option in gnome-control-center: https://bugzilla.gnome.org/show_bug.cgi?id=682457 The good news is it seems to be taken seriously. The bad news is it seems to be rife with difficulties...
*** Bug 748244 has been marked as a duplicate of this bug. ***
*** Bug 761447 has been marked as a duplicate of this bug. ***
*** Bug 760569 has been marked as a duplicate of this bug. ***