GNOME Bugzilla – Bug 765907
[Wayland] Reversed scrolling GDK_SCROLL_UP/GDK_SCROLL_DOWN in Wayland
Last modified: 2016-05-28 18:49:41 UTC
Created attachment 327159 [details] Simple reproducer program This is a follow up of bug 764595 When there are a lot of entries in a GtkMenu, using the mouse wheel under Wayland to scroll through the list moves the items in the wrong (natural) direction. Also, using the touchpad to scroll through the list of entries is very slow. No such issue under X11. Attaching a simple reproducer. Steps to reproduce: 1. Save and build the source $ gcc menuitems.c -o menuitems -Wall `pkg-config gtk+-3.0 --cflags --libs` 2. Run under Wayland 3. Open the menu and try to scroll through the list of entries using themouse wheel of the touchpad. Expected results: When using the mouse wheel, the items scroll in the expected direction. Using the touchpad, the entries scroll fast enough. Actual results: Mouse wheel scrolls in the opposite direction, and scrolling with the touchpad is very slow.
Sorry, for step #3 in comment 0 I meant "Open the menu and try to scroll through the list of entries using the mouse wheel _or_ the touchpad."
OK, so it all comes down to gdk events... With X11 backend, using the mouse wheel we get GDK_SCROLL_UP when rolling the wheel toward the front and GDK_SCROLL_DOWN when rolling the mouse wheel toward the back (this is expected with my current setup, not using "natural" scrolling). When usign the touchpad, we also get GDK_SCROLL_SMOOTH events, but the GDK_SCROLL_UP/GDK_SCROLL_DOWN take precedence in gtk_menu_scroll() https://git.gnome.org/browse/gtk+/tree/gtk/gtkmenu.c#n3551 so we always scroll by MENU_SCROLL_STEP2. With the Wayland backend, we get the opposite, using the mouse wheel we get GDK_SCROLL_DOWN when rolling the wheel toward the front and GDK_SCROLL_UP when rolling the mouse wheel toward the back, which explains why the scrolling goes int he opposite direction (as compared to the X1 backend). When using the the touchpad on the menu under Wayland, we get only GDK_SCROLL_SMOOTH so we scroll by the value provided by event->delta_y which is much smaller than MENU_SCROLL_STEP2, which explains why the scrollign is much slower than under X11.
humm, could it be a possible mix up between mutter and gtk+? mutter sets y_discrete as 1 for SCROLL_DOWN and -1 for SCROLL_UP https://git.gnome.org/browse/mutter/tree/src/wayland/meta-wayland-pointer.c#n624 Whereas gtk+ takes y_discrete > 0 as SCROLL_UP and y_discrete < 0 as SCROLL_DOWN https://git.gnome.org/browse/gtk+/tree/gdk/wayland/gdkdevice-wayland.c#n1132
Created attachment 327202 [details] [review] [PATCH] wayland: fix up/down mix up in discrete events The wayland specification for discrete step information for scroll and other axes reads: | The discrete value carries the directional information. e.g. a | value of -2 is two steps towards the negative direction of this axis. mutter sets a value of 1 for SCROLL_DOWN events and -1 for SCROLL_UP events. gdkdevice Wayland backend does the opposite, it translates a positive discrete value as SCROLL_UP and a negative value as SCROLL_DOWN, which ends up inverting the scrolling direction. Fix the logic in gdkdevice Wayland to use a positive value as SCROLL_DOWN and a negative value as SCROLL_UP so that it matches mutter and weston logic.
Comment on attachment 327202 [details] [review] [PATCH] wayland: fix up/down mix up in discrete events Indeed. I guess this went unnoticed with the various natural scrolling settings confusing things.
Thanks, OK to push in 3.20 as well?
Sure, makes sense to backport
Comment on attachment 327202 [details] [review] [PATCH] wayland: fix up/down mix up in discrete events attachment 327202 [details] [review] pushed as commit e74ecfe in master and commit a537bdc in branch gtk-3-20 - wayland: fix up/down mix up in discrete events
*** Bug 764601 has been marked as a duplicate of this bug. ***
I do see this issue again with gtk+ 3.21.1 (Fedora 24 guest session on a Fedora 25 (rawhide) host).