Feature Request: Send mouse scroll events from encoder rotations, instead of page up/down

[petejohanson]

Sending page up/down on encoder rotation only supports scrolling the actively focused content on most OSes. If we instead were to expose a HID mouse/trackpad, and send vertical scroll events, the experience may be improved for many scenarios.

1. Add an additional HID report to the descriptor for mouse events.
2. Add API to send mouse report updates.
3. Hook those to a new behavior you could bind to the encoder sensor location.

[tominabox1]

Would this feature also include general implementation of mouse keys?

[petejohanson]

Would this feature also include general implementation of mouse keys?

This and mouse keys would both rely on some of the same underlying HID changes needed, but would be implemented slightly differently, likely.

However, there is distinct API for behaviours reacting to key positions versus sensor events, so we could choice to use one behavior for both if we wanted.

[el-oso]

Hi all, are there any advances on this request? If there is some test code I would like to try it.

[t4corun]

I was able to leverage what was in Nick's repo: compatible = "zmk,behavior-sensor-rotate-var" to make my own behavior that will let me use &mwh and &mmv on a rotary encoder. Got mouse scroll wheel working well on my Rollow's thumb horizontal encoders. You are more than welcome to review it in my zmk-config.

Happy to try to submit a PR but I have very limited knowledge here and don't want to mess something up

[pmalecka]

Trying to make this work on the new PR (#2027) as well as on top of Nick's repo (linked by @t4corun above), but the scroll wheel binding does not seem to work for me..

Here's the behavior I'm using

scroll_up_down: behavior_sensor_rotate_mouse_wheel_up_down {
	compatible = "zmk,behavior-sensor-rotate";
	#sensor-binding-cells = <0>;
        bindings = <&msc SCRL_UP>, <&msc SCRL_DOWN>;
};

then it's defined in the keymap:

sensor-bindings = <&scroll_up_down>;

I'm obviously missing something, as the scroll works when mapped to a key, but does not work when mapped to the encoder.

[caksoylar]

It is probable that the scrolling signal sent isn't enough for the computer to translate to an actual scroll, since the duration that encoder sends a tap event is very short by default.
You should add tap-ms to the sensor rotate behavior with a larger value, see https://zmk.dev/docs/config/behaviors#sensor-rotation

If that isn't enough to scroll, you might want to increase the max speed of the scroll behavior; e.g. define a larger ZMK_MOUSE_DEFAULT_SCRL_VAL before #includeing the mouse header or use MOVE_Y(...) (see https://github.com/zmkfirmware/zmk/pull/2027/files#diff-96b6a313b7b2d798a719c2c62671b1244ad8a8830f1b716c7612dc4c92462dc3R47)

[pmalecka]

Thanks for the help!

Had to both to make it work:
tap-ms = <20>;
and
#define ZMK_MOUSE_SCRL_VAL 140

[ctranstrum]

I think this has been completed in #2477.

[nmunnich]

It sort of has sort of hasn't I think - the capability exists, but in a roundabout manner rather than the direct one that would be desired.

[caksoylar]

Given encoders use sensor-rotate behaviors and they use regular behaviors as bindings and mouse scroll is currently implemented as a regular behavior, I don't see an alternate implementation that is more directly tied to encoders.

We should probably document this as an example though, since the tap-ms isn't exposed outside the reference page so it is hard for people to figure out.

[nmunnich]

I recall some discussion on moving encoders to the input API, which is what I was referring to. I wouldn't be opposed to closing this issue and opening one which asks about moving them to the input API though. Agree on example.

[caksoylar]

I guess I'll close, as the OP Pete can reopen if he wants to.