"Reverse scrolling direction" stopped working

[MarjaE2]

Distribution

Fedora 39 t2 + Cinnamon

Package version

6.0.4

Graphics hardware in use

Intel Corporation CoffeeLake-H GT2 [UHD Graphics 630]

Frequency

Always

Bug description

I use Cinnamon > Mouse and Touchpad > Reverse Scrolling direction, to make autoscroll slightly less unintuitive.

A week ago, this worked. If I tried to mouse up and scroll down, I'd scroll down. If I tried to mouse down and scroll up, I'd scroll up.

Now, it's broken. If I try to mouse up and scroll down, it either scrolls up or stops because it's akready at the top and I;m tryikng to scroll down and it can't scroll up any further. If I try to mouse down and scroll up, it scrolls down.

I've tried turning that setting off, still broken, on again, still broken, reboot, still broken.

Steps to reproduce

Open Mouse and Touchpad.

Open an app which supports autoscroll.

Try to autoscroll. Note which way it goes.

Switch "Reverse scroll direction."

Try again to autoscroll. Note which way it goes.

Expected behavior

Enabling "Reverse scroll direction" should give the opposite scroll direction from disabling it.

I don't think it matters which way counts as "normal" or "reverse", as long as users can pick the way theywant and/or need.

Additional information

No response

[MarjaE2]

Maybe this should go under cinnamon-settings-daemon; I think it was fixed here and now broken again: https://github.com/linuxmint/cinnamon-settings-daemon/issues/192

[leigh123linux]

I doubt the issue is caused by cinnamon as I haven't touched f39 for over a month.

https://bodhi.fedoraproject.org/users/leigh123linux

Have you repoted the issue against the app or libinput?

[claudiux]

Curious...

I launch Fedora in a VM.

When I activate "Reverse scroll direction" on my physical machine, the scroll direction is also inverted in the VM. When I activate "Reverse scroll direction" on both, the scroll direction is not inverted in the VM. When I deactivate "Reverse scroll direction" on my physical machine, and activate it in the VM, the scroll direction is well inverted in the VM.

Both "Reverse scroll direction" options are combined.

(I don't have Fedora installed on any physical machine.)

[MarjaE2]

It's stopped working in both Firefox and Xreader, so I don't think it's the apps. I'm not sure how to test libinput or other possibilities.

[MarjaE2]

I've tested in Gnome Classic as well, it's broken there to. So not a Cinnamon issue.

[leigh123linux]

see https://wiki.archlinux.org/title/libinput

$ xinput list
⎡ Virtual core pointer                      id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ Telink Wireless Receiver Mouse            id=9    [slave  pointer  (2)]
⎜   ↳ Telink Wireless Receiver Consumer Control 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)]
    ↳ Video Bus                                 id=7    [slave  keyboard (3)]
    ↳ Power Button                              id=8    [slave  keyboard (3)]
    ↳ Telink Wireless Receiver System Control   id=11   [slave  keyboard (3)]
    ↳ Telink Wireless Receiver                  id=12   [slave  keyboard (3)]
    ↳ Telink Wireless Receiver Consumer Control id=13   [slave  keyboard (3)]

$ xinput list-props 9 |grep Natural
    libinput Natural Scrolling Enabled (305):   0
    libinput Natural Scrolling Enabled Default (306):   0

after toggling it on in cinnamon-settings

$ xinput list-props 9 |grep Natural
    libinput Natural Scrolling Enabled (305):   1
    libinput Natural Scrolling Enabled Default (306):   0

Maybe file the issue against libinput at redhat bugzilla as the fedora maintainer is also the upstream maintainer.

[leigh123linux]

@whot

[whot]

xinput list-props 9

fwiw, you can do xinput list-props "Telink Wireless Receiver Mouse" which will remain stable, unlike the device ids.

What happens if you run sudo libinput debug-events --enable-natural-scrolling? Does it show the correct scroll directions (double-check with --disable-natural-scrolling too)? If so then libinput itself at least works so the problem is likely in the driver or elsewhere.

[MarjaE2]

sudo libinput debug-events --enable-natural-scrolling

The Terminal goes haywire and I have to quit it.

[whot]

Probably best to run it with the --grab option which will make all devices go to that process exclusively so nothing else (including X/Wayland) will receive events. Having said that: this command starts a second libinput context which prints to stdout, it has no influence on the running context. so if the terminal goes haywire, that indicates a client bug.

[MarjaE2]

If I run sudo libinput debug-events --enable-natural-scrolling, I get a series of POINTER MOTION results. I don't know if these are coordinates. But if I move my mouse to try to figure these out, I get too many, too fast.

If I open xreader in another window and autoscroll in xreader, I do not get any results unless I'm actively moving the mouse.

[whot]

debug-events' POINTER_MOTION include the motion coordinates, yes (accelerated and unaccelerated in parenthesis). These are deltas, not absolute coordinates.

As mentioned in the libinput issue autoscroll is implemented by the application based on (I guess) the distance to the original click point. This isn't something that libinput can handle since no-one other than the application knows that there's even scrolling going on.