pulseaudio scrolling goes in what feels the wrong direction, negative scroll-step not supported

[chris-morgan]

trafficstars

waybar 0.9.7, Arch Linux, “natural scrolling” enabled on my laptop’s touchpad.

Two parts to this:

1. On a pulseaudio widget, swiping two fingers upwards causes volume to go down. I expect this action to make it go up. (If I disable natural scrolling, it does.)

   I will note that <input type=number> in Firefox treats scrolling the same way that waybar-pulseaudio is. I find this just as disconcerting and wrong. I haven’t tried anything else to see if it’s universal or not.

   It’s distinctly possible that this sort of control should be one of the rare things that actually ignores the natural scrolling setting.

2. In order to work around this, I try setting scroll-step to a negative value, which should certainly work. But instead it causes scrolling to just do nothing.

[OJFord]

This is (probably - it is in my case) a consequence of having 'natural scroll' enabled, for example in swayconfig:

input type:touchpad {
  natural_scroll enabled
}

This is unexpected, because in the case of volume the default (natural_scroll disabled) behaviour is more, er, natural.

(Edit: oh sorry, definitely is in OP's case and seems you recognised that too, glossed over the first sentence.)

Perhaps it wasn't possible when you posted, but a workaround that does work is overriding on-scroll-{up,down} to switch them around.

Of course, this only works (as negative step would too) if you exclusively use a 'natural scroll' touchpad; never a mouse scrollwheel for example or any input that isn't configured as natural_scroll enabled.

[JayceFayne]

fixed by https://github.com/Alexays/Waybar/pull/1289

[OJFord]

That's just the mentioned work-around by a different method though really, doesn't help when you sometimes use a natural_scroll device and sometimes not - probably common among 'clamshell' users, a mouse when docked and a possibly-natural touchpad otherwise.

[korylprince]

This has been bugging me, so I've been investigating ways to fix this.

The type of input that is scrolling can be detected from the GTK scroll event.

GdkEventScroll.get_source_device().input_source can be checked to see if the input is a mouse, touchpad, or trackpoint. (GTK-wayland code here)

I propose two solutions to allow intuitive scrolling for mice and touchpads simultaneously:

• Ignore the "reverse-scrolling" option when the scroll event is generated by a mouse
  • I can't think of why anyone would actually want "natural scrolling" on a mouse wheel, and this would be an easier change...
• Allow configuring "reverse-scrolling" for mice and touchpads separately
  • For backwards compatability, you could keep "reverse-scrolling" as a global on/off, and add "reverse-mouse-scrolling" and "reverse-touchpad-scrolling" to configure separately?

@Alexays, I'm happy to do a PR for this, but before I write the code, I want to make sure you're willing to accept one of the two above changes...

Edit: I went ahead and submitted a PR for option 1, since it's not that much code.