Mpv: MOUSE_BTN3 and MOUSE_BTN4 behaviours not changing in input.conf

[Masishta]

mpv version and platform

mpv-x86_64-20170718 Windows build

Reproduction steps

add "MOUSE_BTN3 add volume 5" to input.conf for example

Expected behavior

mouse wheel should change volume by %5

Actual behavior

mouse wheel still use seek option by default which is seeking by 10 seconds

[wiiaboo]

It's AXIS_UP and AXIS_DOWN now.

[aufkrawall]

Is this supposed to be for Windows only? On Linux it's still old behavior, so the same config entries lead to different behavior.

[wiiaboo]

In Windows it's been changed to always AXIS_UP and AXIS_DOWN, at least for notched mouse wheels. Dunno about Linux, but I think there they could mean different things. @rossy can explain better.

[rossy]

Yeah, on macOS and Linux/Wayland, AXIS_UP and AXIS_DOWN mean different things to BTN3 and BTN4. The AXIS events are used for devices that do precise scrolling, like touchpads and mice with gesture scrolling, and BTN3/4 are used for notched scroll wheels. This is because the AXIS events can "scale" the input commands, so for example, if you have AXIS_UP bound to add volume 10 and you scroll half a unit (where a "unit" of scrolling is some device-specific amount,) it will increase the volume by 5.

On Windows, I couldn't find a way to differentiate between precise and non-precise scroll events, so all devices now send AXIS_UP and AXIS_DOWN. On Linux/X11 it's the opposite: We don't use XInput 2.1 yet, so we can't get precise scrolling deltas on X11 even from precise devices, hence all devices send MOUSE_BTN3 and MOUSE_BTN4, which never scale their input commands.

I'm not sure this behaviour is the best. It might be less confusing for the user if we found a way to unify the AXIS and BTN3/4 events, but I can't think of a good way to do that.

[Masishta]

AXIS_UP and AXIS_DOWN is working. Fortunately we can see buttons name inside mpv.
thank you

[haasn]

@rossy Btw, is there any way this change could have been communicated better? AFAIK it doesn't even show up in the release notes.

I also think the weird platform-specificness is, well, weird.

[rossy]

@haasn Yeah, my bad. I was trying to think of a way to unify the AXIS and MOUSE_BTN events, but I didn't get to it before the 0.26.0 release, so BTN3/4 bindings were broken on Windows without warning. I think mouse wheel bindings are a pretty major point of user confusion, so I'd like to get this fixed.

One aspect that I'm worried about is that someone on Wayland or macOS could potentially have had the MOUSE_BTN and AXIS events bound to different commands (so touchpad scrolling on their MacBook would run different commands to wheel scrolling on a regular USB mouse.) If we end up deprecating MOUSE_BTN3/4 and replacing it with the AXIS events, that could break this usage on Wayland and macOS, just because of a Windows limitation.

[ghost]

Probably should have been in interface-changes or so at least.