GNOME Bugzilla – Bug 758659
Magic Mouse and touchpad have opposite scrolling
Last modified: 2015-12-11 13:05:47 UTC
I have a touchpad and a Magic Mouse (Bluetooth) connected. Running libinput-debug-events on each of them, shows that for both devices, moving my fingers upwards generates a negative vertical scroll delta, and moving them downwards generates a positive vertical scroll delta. Regardless, somehow, when running under mutter-wayland, the two are at opposites: my touchpad retains the libinput polarity (moving fingers up -> negative delta), whereas the Magic Mouse is inverted (moving fingers up -> positive delta). I'm at a bit of a loss as to where this would happen inside Clutter/Mutter, but happy to try to work it out if someone can point me in the right direction.
note that libinput-debug-events is a separate process and does not use the same settings mutter may have applied, so there's a chance that you have natural scrolling enabled for the mouse but not on the touchpad. Should be easy enough to narrow down, make libinput_device_config_scroll_set_natural_scroll_enabled() a noop and see if that changes things. If so, then you need to figure out which setting triggers this. Check this first too: gsettings set org.gnome.desktop.peripherals.mouse natural-scroll false
Wunderbar, GSettings has fixed it - thanks! I wonder how on earth the two ever got out of sync.
I'm guessing that's fixed. There's a button for that in new mouse and touchpad panel.
There's _a_ button in the touchpad section of the Mouse & Touchpad settings, yes. My touchpad behaved as expected (natural == false), but the mouse behaved in exactly the opposite manner (natural == true). So something was broken in g-s-d/g-c-c as the two settings were out of sync. Poking the GSetting manually made it work again. No idea if this is actually fixed in general or not.
(In reply to Daniel Stone from comment #4) > There's _a_ button in the touchpad section of the Mouse & Touchpad settings, > yes. My touchpad behaved as expected (natural == false), but the mouse > behaved in exactly the opposite manner (natural == true). So something was > broken in g-s-d/g-c-c as the two settings were out of sync. The "new" in comment 3 being the important word. It's not been released, but I thought you were using jhbuild. > Poking the GSetting manually made it work again. No idea if this is actually > fixed in general or not. You hit bug 759305.
(In reply to Bastien Nocera from comment #5) > (In reply to Daniel Stone from comment #4) > > There's _a_ button in the touchpad section of the Mouse & Touchpad settings, > > yes. My touchpad behaved as expected (natural == false), but the mouse > > behaved in exactly the opposite manner (natural == true). So something was > > broken in g-s-d/g-c-c as the two settings were out of sync. > > The "new" in comment 3 being the important word. It's not been released, but > I thought you were using jhbuild. I am, but 3.18.x rather than master. If there are separate settings for mouse and touchpad in master, I've not seen those as I'm still running 3.18.x. > > Poking the GSetting manually made it work again. No idea if this is actually > > fixed in general or not. > > You hit bug 759305. ITYM bug 759304, but regardless, it doesn't seem related ... ? Two-finger scrolling was always enabled for both devices. The bug is that they had opposite polarity, despite there only being a single checkbox in g-c-c to switch that polarity. To be clear: - settings -> Mouse & Touchpad: natural scrolling OFF - touchpad: two-finger scrolling on, behaved as if natural scrolling OFF - Magic Mouse: two-finger scrolling on, behaved as if natural scrolling ON So unless there's been a fix to 3.18.x that keeps the separate {mouse,touchpad}.natural-scrolling settings in sync, this is still an issue. I don't have a good answer as to how mouse.natural-scrolling came to be true, as I've never enabled natural scrolling, nor played with those GSettings.
(In reply to Daniel Stone from comment #6) > (In reply to Bastien Nocera from comment #5) > > (In reply to Daniel Stone from comment #4) > > > There's _a_ button in the touchpad section of the Mouse & Touchpad settings, > > > yes. My touchpad behaved as expected (natural == false), but the mouse > > > behaved in exactly the opposite manner (natural == true). So something was > > > broken in g-s-d/g-c-c as the two settings were out of sync. > > > > The "new" in comment 3 being the important word. It's not been released, but > > I thought you were using jhbuild. > > I am, but 3.18.x rather than master. If there are separate settings for > mouse and touchpad in master, I've not seen those as I'm still running > 3.18.x. > > > > Poking the GSetting manually made it work again. No idea if this is actually > > > fixed in general or not. > > > > You hit bug 759305. > > ITYM bug 759304, but regardless, it doesn't seem related ... ? I meant https://bugzilla.gnome.org/show_bug.cgi?id=758740 Copied the wrong bug URL from gsettings-desktop-schemas. > Two-finger scrolling was always enabled for both devices. The bug is that > they had opposite polarity, despite there only being a single checkbox in > g-c-c to switch that polarity. > > To be clear: > - settings -> Mouse & Touchpad: natural scrolling OFF > - touchpad: two-finger scrolling on, behaved as if natural scrolling OFF > - Magic Mouse: two-finger scrolling on, behaved as if natural scrolling ON > > So unless there's been a fix to 3.18.x that keeps the separate > {mouse,touchpad}.natural-scrolling settings in sync, this is still an issue. > > I don't have a good answer as to how mouse.natural-scrolling came to be > true, as I've never enabled natural scrolling, nor played with those > GSettings. I don't know how it would have changed, but there are 2 separate settings in 3.19.x (in master) so that will be the proper fix for the problem. The code in gnome-control-center in 3.18.x only ever changed the touchpad natural-scroll settings, never the mouse settings.
Well, that all makes sense then. g-c-c 3.18.x flips the trackpad setting, but for a while, the default for mouse was natural-scrolling==TRUE, with no way to change it apart from GSettings, so it was intentional. 3.18.x remains broken, but oh well.
(In reply to Daniel Stone from comment #8) > Well, that all makes sense then. g-c-c 3.18.x flips the trackpad setting, > but for a while, the default for mouse was natural-scrolling==TRUE, with no > way to change it apart from GSettings, so it was intentional. No, it was only enabled in 3.19.x for mice. The setting was added in b5b48a823fae09a7cb749d0a67d235ef098b490a (in gsettings-desktop-schemas) and hasn't changed since. > 3.18.x remains broken, but oh well. The default hasn't changed in 3.18. It's disabled for mice, and there wasn't a way to change natural-scroll in the UI. Something or somebody changed the settings on your system, but it's not the Mouse & Touchpad panel or changes or defaults in 3.18.
(In reply to Bastien Nocera from comment #9) > (In reply to Daniel Stone from comment #8) > > 3.18.x remains broken, but oh well. > > The default hasn't changed in 3.18. It's disabled for mice, and there wasn't > a way to change natural-scroll in the UI. > > Something or somebody changed the settings on your system, but it's not the > Mouse & Touchpad panel or changes or defaults in 3.18. Assuming that I didn't change it, nor did someone compromise my machine specifically to change it, let's chalk it up to branches again failing to be tracked in jhbuild, perhaps.
(In reply to Daniel Stone from comment #10) > (In reply to Bastien Nocera from comment #9) > > (In reply to Daniel Stone from comment #8) > > > 3.18.x remains broken, but oh well. > > > > The default hasn't changed in 3.18. It's disabled for mice, and there wasn't > > a way to change natural-scroll in the UI. > > > > Something or somebody changed the settings on your system, but it's not the > > Mouse & Touchpad panel or changes or defaults in 3.18. > > Assuming that I didn't change it, nor did someone compromise my machine > specifically to change it, let's chalk it up to branches again failing to be > tracked in jhbuild, perhaps. That's probably what happened. See bug 759347 about fixing this problem once and for all.