It's also the same, consistent direction one interacts with content on touch-screens.

Garrett - can you describe the natural scrolling behaviour for a mouse? (Is it specific to scroll wheels? Does it affect the behaviour of scroll bars?) I'm subscribing Ondrej, who has been working on this feature for us.

The idea is that you push the content around, in the same direction, no matter the input device. The scrollbars are basically position indicators. 

If one does interact with scrollbars… then it works the same as it does now, as then one is no longer interacting with the content, but the scrollbar.

Natural scrolling for touchpads use xinput Synaptics Scrolling Distance values, but for mouse there isn't such property and solution switching buttons map doesn't work everywhere unfortunately.

Do you have any idea how to do that?

Nope! But it used to work everywhere before GNOME 3.4 for me. Something changed with the move to xinput2 with the newer versions of GTK+ and GNOME. 

(Some apps are even using a mix of the two types for the scrollable areas.)

What was introduced recently is smooth scrolling, which instead of the previous button 4/5 presses sends motion events with the valuator data for the scroll wheel. same for synaptics, though that one has artificial axes for scrolling.

Natural scrolling _should_ be a client-side interpretation. The device sends "two units down" and the client then interprets this according to the natural scrolling setting. Alas, that didn't happen in time so we've added support to synaptics for negative scroll increments. This makes the device send inverted scroll events even without client-side support.

The evdev driver doesn't have this setting and smooth scrolling isn't affected by button mappings. So the combination you may now have is a client that listens to smooth scrolling events but doesn't handle natural scrolling itself. So any button mapping won't do anything, since the button events are ignored by the client.

(In reply to comment #6)

Thanks for the information, Peter. Is there any chance of resolving this issue?

I doubt about, because for mouse there isn't "Scrolling Distance" property, which is used for touchpad natural scroll...

Main point:

It's not treated as analog input, but I'm talking about matching the direction for consistency.


Reply to Ondrej's mention of "scrolling distance":

There is definitely a scrolling distance chosen for a mouse wheel up/down event. Typically, it's not treated as an analog event, but maps to a specified number of pixels or steps, depending on the environment, application, or mode of application (such as shift+wheel to zoom).

The implementation would pretty straight forward for GTK+ apps (add an XSettings that maps to a GtkSettings, and make widgets that use the scroll wheel reverse the 2 values), but it would mean a different behaviour in GTK+ and non-GTK+ apps.

(In reply to comment #9)
> Reply to Ondrej's mention of "scrolling distance":
> 
> There is definitely a scrolling distance chosen for a mouse wheel up/down
> event.

But there's no property to set it. It's sent in the event's valuators, and the only way to change the meaning is by making the widget set do the inversion. See above.

(In reply to comment #7)
> Thanks for the information, Peter. Is there any chance of resolving this issue?

workaround for now:
it turns out we do still respect button mappings properly. So for legacy apps I recommend changing the device button mapping when reverse scrolling is enabled. this will cause legacy button events to be inverted and in-line with the GTK apps.

it won't bring other smooth-scrolling apps in-line but it may provide the 90% solution at least.

(In reply to comment #11)
> (In reply to comment #7)
> > Thanks for the information, Peter. Is there any chance of resolving this issue?
> 
> workaround for now:
> it turns out we do still respect button mappings properly. So for legacy apps I
> recommend changing the device button mapping when reverse scrolling is enabled.
> this will cause legacy button events to be inverted and in-line with the GTK
> apps.
> 
> it won't bring other smooth-scrolling apps in-line but it may provide the 90%
> solution at least.

I'm afraid that we'd probably get too many bug reports about this. Is a more generic (X.org level) solution forthcoming, or even possible, for this? I'm fine with waiting.

one of the relatively easy things to is to provide a request to change the increment setting. This would then cause everyone to adjust and it would also allow for slowing down or speeding up scrolling.

How to integrate the button mapping I'm not sure tbh, other than the relatively hacky approach of including the 4/5/6/7 button map in that request so both are changed at the same time.

*** Bug 703643 has been marked as a duplicate of this bug. ***

(In reply to comment #12)
> I'm afraid that we'd probably get too many bug reports about this.

Indeed we have. And they eventually all lead back to here. Should this bug not at least be marked CONFIRMED?

(In reply to comment #15)
> (In reply to comment #12)
> > I'm afraid that we'd probably get too many bug reports about this.
> 
> Indeed we have. And they eventually all lead back to here. Should this bug not
> at least be marked CONFIRMED?

We don't use UNCONFIRMED/NEW with special meaning in GNOME.

This is indeed quite an frustrating problem. Like others here I've setup natural scrolling on my trackpad/mouse and it works wonderfully with the exception of GTK apps when using the scroll wheel on the mouse. 

Is there at least a hack that we could apply? I'd be perfectly happy with a hack I have to do myself that would get scrolling consistent across applications, as its quite annoying to switch to a GTK app and be confused for a second when scrolling.

Wow... it's almost a year and a half and this issue still hasn't recieved any attention. I can't wait for Unity 8.

Is there no way to get rid of smooth scrolling? I'd rather have natural scrolling than smooth scrolling (which doesn't work in the applications I use anyway)

I don't think so we can disable smooth scrolling, so the hack with button map doesn't work consistently...

(In reply to comment #18)
> Wow... it's almost a year and a half and this issue still hasn't recieved any
> attention. I can't wait for Unity 8.

Don't let the door hit you on the way out...

This bug just hit me after updating Quod Libet from 2.x to 3.x. I use KDE as desktop, but I don’t mind using gnome-applications.

Inconsistent scrolling directions are very frustrating, though, which might freeze me to gtk2 until this issue is resolved.

Ubuntu 14.04 is here and this problem still exists -- and in fact is getting worse as more and more apps are using gtk3. I am having to seriously consider giving up my beloved linux box for work and going back to windoze noooooo! I am willing to test, project manage, whatever helps get this addressed...

So to summarize where we're at:

* gtk3 supports smooth scrolling
* smooth scrolling doesn't use mouse codes 4/5 for scroll up/down
* so reversing codes 4/5 (e.g. in xmodmap) has no effect in gtk3 apps

Peter Hutterer appears to have the best grasp on the root problem:

(In reply to comment #6)
> Natural scrolling _should_ be a client-side interpretation. The device sends
> "two units down" and the client then interprets this according to the natural
> scrolling setting. Alas, that didn't happen in time so we've added support to
> synaptics for negative scroll increments. This makes the device send inverted
> scroll events even without client-side support. 

When I run "xinput --test" and scroll the mousewheel I see two different types of signals for each: it is reported as "button press 4" and "button press 5" for up and down respectively, but a scroll in either direction is also reported as a minus/plus change to "motion a[3]". For example:

motion a[3]=-335
button press   5 
button release 5 
motion a[3]=-336 
button press   5 
button release 5 
motion a[3]=-335 
button press   4 
button release 4 
motion a[3]=-334 
button press   4 
button release 4 

Peter, is motion a[3] what you are referring to in "The device sends 'two units down'"? What is "the client" that needs to interpret this parameter? something in gtk3?

(In reply to comment #13)
> one of the relatively easy things to is to provide a request to change the
> increment setting. This would then cause everyone to adjust and it would also
> allow for slowing down or speeding up scrolling.

Peter, any chance you could elaborate in more detail on what you mean by "provide a request to change the increment setting"?

FWIW evdev seems to have gained support in the time since Peter's original comment. The method described at http://forums.fedoraforum.org/showthread.php?t=298702 is working for me.

(In reply to comment #24)
> FWIW evdev seems to have gained support in the time since Peter's original
> comment. The method described at
> http://forums.fedoraforum.org/showthread.php?t=298702 is working for me.

I've been down that path and it doesn't work for me. xinput does not show a "Scrolling Distance" property on my mouse:

$ xinput
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ USB Optical Mouse                       	id=8	[slave  pointer  (2)]
⎜   ↳ Logitech Logitech Illuminated Keyboard  	id=10	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Power Button                            	id=7	[slave  keyboard (3)]
    ↳ Logitech Logitech Illuminated Keyboard  	id=9	[slave  keyboard (3)]
$ xinput --list-props 8 | grep -i Scroll
$ 

I tried adding the 20-natural-scrolling.conf file as specified anyway and rebooting -- does nothing.

Where is this Scrolling Distance property supposed to come from? Is it something to do with the physical mouse itself? This a basic Dell 3-button optical mouse. But I also tried it with a Macally mouse I bought brand new a few weeks ago, and it doesn't show a "Scrolling Distance" property either.

Aron, what do you mean exactly by "evdev seems to have gained support"? Support in what?

You can try it out with:
xinput set-prop 9 "Evdev Scrolling Distance" -1 -1 -1
with "9" being the input device.

Except that you'll find it doesn't work with a lot of different devices, or breaks others. We don't set the natural scrolling for anything but touchpads right now, so if you have different directions between GTK2 and GTK3 apps, it's not due to that...

All this should be fixed when libinput has support (shortly) and we either use X11 and the libinput based driver, or Wayland. Yes, a little more patience will be required.

Tried it with a logitech mouse and a microsoft mouse, neither of them show the Scrolling Distance property either.

Here's what I get trying to set it on the fly:

$ xinput set-prop 8 "Evdev Scrolling Distance" -1 -1 -1
property 'Evdev Scrolling Distance' doesn't exist, you need to specify its type and format

OMGOMG I found a workaround that actually works for me:

http://askubuntu.com/questions/137444/is-there-anyway-to-enable-system-wide-inverse-scrolling

Not the popular answer (that's the old "NaturalScrolling" applet that doesn't work anymore) but the answer further down by D. Charles Pyle, who seems to be the same guy that wrote the Fedora how-to that Aron referred to above, BUT this time he added an "alternate method" for those of us that don't have a Scrolling Distance property, which looks surprisingly similar to the xmodmap hack, but actually works in both GTK2 and GTK3 apps!

Perhaps this is not the proper fix to the actual bug in this case, I'm just noting it here for other lost souls that come across this.

(In reply to comment #27)
> $ xinput set-prop 8 "Evdev Scrolling Distance" -1 -1 -1
> property 'Evdev Scrolling Distance' doesn't exist, you need to specify its type
> and format

Ubuntu ships with evdev 2.8.1, the property became available in 2.9.0

(In reply to comment #28)
> Not the popular answer (that's the old "NaturalScrolling" applet that doesn't
> work anymore) but the answer further down by D. Charles Pyle, who seems to be
> the same guy that wrote the Fedora how-to that Aron referred to above, BUT this
> time he added an "alternate method" for those of us that don't have a Scrolling
> Distance property, which looks surprisingly similar to the xmodmap hack, but
> actually works in both GTK2 and GTK3 apps!
> 
> Perhaps this is not the proper fix to the actual bug in this case, I'm just
> noting it here for other lost souls that come across this.

this fix effectively disables the evdev driver and enables the old mouse driver instead. that driver doesn't do smooth scrolling, so the button mapping works. fwiw, Fedora doesn't ship that driver anymore. You'd get duplicate devices with that one too afaict, if you have multiple pointers each button event would be a double click.

Thanks Peter, that makes sense and is good to know. I figured I would want to revert the mouse driver hack at some point, and I guess that'll be when Ubuntu starts using evdev 2.9.0.. does anyone know if that's got a target release yet? Or are there complications in the way?

2.9 uses libevdev as backend so it's unlikely that it will be backported to U14.04, but will likely be in the next version. The property patches should be backport-able, see commits d171b3d9194581cb6ed59dbe45d6cbf009dc0eaa and the one before. File a bug against evdev on freedesktop.org, test the cherry-picks on the evdev-2.8-branch and attach them there. I can push them to evdev 2.8.5 if it works (but you'll have to do the cherry-picking/testing work :)

Well if it's likely to make it into the next Ubuntu version then the workaround is fine for me until then (48 hours ago I would have jumped on it). That said, I could possibly be talked into working on a patch if enough other people would like to see it backported?

Though there would ideally be a checkbox added to system settings at the same time, which is perhaps a bit much for a backport...

> http://askubuntu.com/questions/137444/is-there-anyway-to-enable-system-wide-inverse-scrolling

WARNING: THIS SOLUTION CAN DISABLE KEYBOARD.

rob -- what version of evdev did you install? i just installed 2.9.0-1 and the result was my keyboard not working. had to start up in recovery mode to downgrade... i'm back up and running, but now i need to fix some fn keys...

if you are on the following, i definitely DO NOT RECOMMEND this solution:
- gnome ubuntu 14.04.1
- gnome shell 3.10
- 3.13.0-40-generic


(In reply to comment #28)
> OMGOMG I found a workaround that actually works for me:

just to note i *did not* follow the "alternate method" -- i am about to try this w/o upgrading evdev...

sorry for the consecutive posts. the suggested alternate method definitely works! thanks for the post rob, this has been driving me insane.

to clarify (so someone doesn't en up w/ the same problem i did) -- just add this:

Section "InputClass"
        Identifier "natural scrolling for mouse wheel"
        MatchIsPointer "on"
        MatchDevicePath "/dev/input/event*"
        Driver "mouse"
        Option "Device" "/dev/input/mice"
        Option "Protocol" "Auto"
        Option "ZAxisMapping" "5 4"
EndSection

to a conf file file in /usr/share/X11/xorg.conf.d/

Hi there!

Thanks to your solution I finally got Nat.Scrolling working even in GTK apps.
But failed I to accomplish this for horizontal scrolling, too. I'm on 12.04.5 and therefore followed http://manpages.ubuntu.com/manpages/precise/man4/mousedrv.4.html by adding
Option "ZAxisMapping" "5 4"
to my 20-natural-scrolling.conf.

Any ideas?

Option "ZAxisMapping" "5 4 7 6"    I meant.
Option "ZAxisMapping" "5 4 9 8"    doesn't work, neither.

This should now work with the X11 libinput driver, but we don't advertise it in the Mouse panel.

We should probably apply it to all new devices, and move the setting to the generic part of the UI, instead of just for touchpads.

Might want to double-check that mutter applies it as well.

This has been fixed in the mouse panel redesign done for GNOME 3.20. See bug 756863.