[Feature request] Mouse scroll up/down remapping, sending mouse scroll and movement events

[ristomatti]

I didn't find a previous request about this. I do not know how feasible this would be given #21 for example.

QMK allows mapping keys to both mouse wheel events and mouse movement. That would be handy for some situations but most of the time it'd need to be context dependent, so I rarely use the feature. If keymapper could do this, it could be a lot more practical.

Remapping mouse wheel events would be useful for something like this:

[title="Spotify"]
MouseWheelUp >> AudioVolumeUp
MouseWheelDown >> AudioVolumeDown

[default]
(Meta Alt){MouseWheelUp}   >> send_window_to_previous_workspace
(Meta Alt){MouseWheelDown} >> send_window_to_next_workspace

Meta{MouseWheelUp}         >> goto_previous_workspace
Meta{MouseWheelDown}       >> goto_next_workspace

What do you think?

[houmain]

Thanks for requesting. I already thought but adding mouse wheel support but since it is not trivial to implement on all platforms I did not do it yet. But I will try it.

[kbilsted]

looking forward to this :)

[houmain]

This is now testable in the 4.2.0 release. The keys are called WheelUp and WheelDown.

[kbilsted]

is it for all platforms

[houmain]

Windows and Linux. MacOS does not have mouse support yet.

[ristomatti]

Does the implementation include both input and output mappings? As a test I added a mapping to scroll virtual desktops with something like this:

[device = MouseG502X, modifier = "ButtonSide"]
  WheelDown               >> Meta{Tab}
  WheelUp                 >> Meta{Shift{Tab}}

It worked like a charm on first try. However when tested it on the output side, nothing happened. I then also noticed the default mouse scroll has stopped working also. I tried removing all WheelUp/Down changes from the config, but still the same result. Only after stopping keymapper the default scrolling worked again.

I then tried putting this on the top of the config:

WheelUp   >> WheelUp
WheelDown >> WheelDown

...but it didn't help either. I wonder if this is something similar to what I found out when fiddling with my Logitech Trackball mouse scrolling. The issue was that udev rules I had defined to make the mouse's trackball to trigger scroll events while pressing a one of it's buttossn did not seem to work. I then found out that if configure pointer:Keymapper with xinput similarly, I got the trackball behavior I wanted.

In this case though, I didn't spot anything different between the output of xinput list-props or xinput get-button-map between my mouse's actual input device and the virtual one created by Keymapper. :thinking:

[ristomatti]

There's no issue or a discussion thread about the new keymapperctl --next-key-info so I'll just throw this in - just tried it and it's a brilliant idea. I can only assume it's intended to be run together with --restart. This pretty much removes the need for debugging using ContextActive and a log file.

Let me know if there's something I could test to help fix the default mouse wheel behavior in case you can't reproduce it. So far I've tried monitoring the events sent by Keymapper's virtual input device using evtest. The wheel events seem to be sent but the OS just doesn't seem to do anything based on them.

Both mice I have are wireless Logitech's paried and configured using Solaar.

[houmain]

Does the implementation include both input and output mappings?

Yes, it should. I think the problem was that I removed the forwarding of REL_WHEEL and only forwarded/generated REL_WHEEL_HI_RES events, because I thought that was enough nowadays (on my machine it worked and I do not have a fancy high-res mouse wheel). Hopefully this is fixed now. Please try again with the 4.3.0 release.

[ristomatti]

The issue is gone, awesome thank you!

[ristomatti]

Forgot to mention, the fact it didn't work for me initially might have something to do with the fact I've got several pointer devices "active"; two Logitech mice with high res wheel, a USB trackball mouse, my laptops integrated trackpoint and one more from my QMK keyboard which supports sending mouse movement/clicks/wheel.

Another, possibly more likely reason is the fact Solaar has special handling for the wheel: