Mouse wheel bindings are controlled by MOUSE_BTN3 and 4 instead of AXIS_UP and AXIS_DOWN

[FichteFoll]

mpv verion

0.20.0 64 bit, Windows 7

Reproduction steps

Try to bind mouse wheel to a different action (or none):

# Volume on mouse wheel
AXIS_UP   add volume 2
AXIS_DOWN add volume -2

Expected behavior

On scrolling, volume should get changed.

Actual behavior

Scrolling still seeks.

[wiiaboo]

Wheel up and down is MOUSE_BTN3 and MOUSE_BTN4, respectively, not AXIS_UP and AXIS_DOWN.

[FichteFoll]

Uh, okay, thanks. It does work indeed.

But this is stupid because the mouse buttons 3 and 4 actually exist and get pushed to 5 and 6 instead, it seems. And because the comments in the default input.conf specifically mention that AXIS_* handles the mouse wheel.

[rossy]

Yeah, this should be fixed. It seems like only the macOS and Wayland backends emit AXIS_UP and AXIS_DOWN. macOS seems to emit AXIS_UP and AXIS_DOWN for touchpads that support precise scrolling and MOUSE_BTN3 and MOUSE_BTN4 for normal scroll wheels. The Windows backend could be changed to support AXIS_UP and AXIS_DOWN, but then MOUSE_BTN3 and MOUSE_BTN4 would stop working because there's no easy way to tell if a scroll event was generated from a device that supports precise scrolling or not. Maybe MOUSE_BTN3 and MOUSE_BTN4 should be deprecated or emulated on top of AXIS_UP and AXIS_DOWN?

[mia-0]

957e9a3