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 710849 - several gtk+ widgets ignore reversed scroll direction
several gtk+ widgets ignore reversed scroll direction
Status: RESOLVED NOTABUG
Product: gtk+
Classification: Platform
Component: .General
3.10.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
: 709960 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-10-25 00:50 UTC by jacob
Modified: 2014-09-18 12:30 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description jacob 2013-10-25 00:50:27 UTC 
Several Gtk+ apps are unaffected when using Xorg's evdev driver to remap mouse buttons such that the scroll wheel is reversed.  Under this setting, these widgets then scroll in the opposite direction from other applications.  I began to notice this in a few types of widgets from gtk 3.8, but it has become even more prevalent in 3.10.

Steps to reproduce:
* Open any pdf in evince 3.10.0
* enter in a terminal:
  $ xinput set-button-map 'Name_of_pointer_device' 1 2 3 5 4

Expected behavior:
The direction of vertical scrolling reverses

Observed behavior:
No change in scrolling behavior.  The affected widgets now scroll in the opposite direction to unaffected applications.

Applications tested:
evince 3.10.0: Most GUI elements are affected by this bug.
evince 3.8.3: The save/open dialog and thumbnails/index sidebar are affected.
  The document itself is not.
pavucontrol 2.0: Main scrollbar and volume sliders are affected.
  Menus are unaffected.
zenity 3.8.0: --file-selection is affected, --calendar is not.
Gtk 2 applications and non-gtk apps are unaffected (produce expected behavior).

Other comments:
I use a bare window manager, without most of the GNOME environment.
Comment 1 Christian Persch 2013-10-25 09:01:40 UTC 
*** Bug 709960 has been marked as a duplicate of this bug. ***
Comment 2 Carlos Garnacho 2014-09-18 12:30:00 UTC 
This has to do with the more spread usage of smooth scroll events, which makes the traditional button-based scroll events ignored. xinput list <your device> will show you the scrolling axes:

		Class originated from: 15. Type: XIScrollClass
		Scroll info for Valuator 2
		  type: 1 (vertical)
		  increment: -1.000000
		  flags: 0x2 ( preferred )

that "increment" value is what determines the directionality/scale of the axis. That value comes directly from the Vert/HorizScrollDelta configuration options, I've also seen an "Evdev Scrolling Distance" property in code, but that one doesn't seem to be fully exported through XI2 properties though :(.

GTK+ has only jumped in the progress bandwagon here, I agree it must be possible to invert these values easily, but it will never be matter of changing the button map again. I suggest you to play with these configuration options and file any evdev driver bug you find on bugzilla.freedesktop.org