Feature: pointer movement/scrolling

[petejohanson]

Continuation of the incremental integration of the great work from @krikun98 in #778 with the movement and scrolling pieces next. Based on the rebased work from @caksoylar and and the split acceleration from @bryanforbes

TODO

• Docs update
• Review acceleration curves/functions configurability
• Review @manna-harbour Discord discussion on per-device scaling factors.
• Review @manna-harbour Discord note on storing float values, and on send of the report discard whole values, but retain the fractional remainder to be included in the follow up calculations, to avoid jerkiness/jumpiness.

[krikun98]

The part that initially made me bang my head against the wall with all this is the fact that Zephyr sometimes seems to de-prioritize these timers if the system is under load.
This is (as far as I was able to understand) the primary cause of the instability with mouse movement - reports can be sent out at random intervals or dropped entirely.
I was exploring re-writing this system to use a dedicated thread, but I wasn't skilled enough at C at the time.
I'm not sure this basis for the tick system is robust enough for general use.

[petejohanson]

So... timers should be using the hardware timers to trigger, and happen in ISR context. The queue has a certain priority, can be preempted, etc. Tweaking that thread priority might help, but I'll play a bit to see what I can determine. Thanks for the insight!

[krikun98]

This is most certainly not definitive - it's a half-remembered conclusion from an investigation I wasn't skilled enough to perform two years ago, just food for thought. I distinctly remember reports being delayed or dropped and that causing instability. hog.c:335 might also be worth taking a look at.

[caksoylar]

I think it might make sense to move these decode defines outside the dt-bindings header, and to either plain mouse.h or the corresponding event headers they are used in.

[petejohanson]

IMHO, they are complementary and should live together.... I think keeping them here is appropriate.

[krikun98]

Could you please change the target to https://github.com/petejohanson/zmk/tree/core/zephyr-3.5-update here? The review is unnecessarily cluttered.

[petejohanson]

Could you please change the target to https://github.com/petejohanson/zmk/tree/core/zephyr-3.5-update here? The review is unnecessarily cluttered.

Unfortunately, that will move the PR into a different GH fork, and make a bit of a mess. I recommend reviewing each commit for clarity for now, until the Zephyr 3.5 bits are merged into ZMK main.

[caksoylar]

I think these are some missed updates for the rebase to account for 36eda571b

[fiplox]

I'd probably try a combination of the two; e.g. try a tap-ms of 50 and see if scroll speed needs increasing.

Adding tap-ms = <100>; does the trick. Thanks.

while adding tap-ms = <100>; makes it work, I find a delay being too big. Playing with parameters, found that tap-ms of 30 with #define ZMK_MOUSE_DEFAULT_SCRL_VAL 35 works almost perfect.

While using this branch I found out that if I use scroll with an encoder and I scroll too fast, the scroll is never released (infinite scroll) and I have to disconnect my keyboard.

[eteq]

Has @petejohanson abandoned this PR? Or is it awaiting review? (If abandoned I might try to pick it up in a follow-on PR but not if @petejohanson is still working on it)

[caksoylar]

This isn't abandoned, I am guessing Studio work is getting more priority right now. Pete mentioned on Discord that he is planning to refactor the endpoints a bit (the current split one has some issues on some OS, like Ubuntu 22.04).

Meanwhile if anyone needs a rebased branch in the very near future, you can cherry-pick from https://github.com/caksoylar/zmk/commits/caksoylar/experimental.

[proostas]

I built a new firmware for my keyboard after the recent changes had been pushed and I noticed a very strange behavior with certain keys.

I have the following settings for mouse behaviors:

&mmv {
    acceleration-exponent = <1>;  // 1
    time-to-max-speed-ms = <300>; // 300
    delay-ms = <0>;
    trigger-period-ms = <8>;      // 16
};
&msc {
    acceleration-exponent = <1>;  // 0
    time-to-max-speed-ms = <40>;  // 300
    delay-ms = <0>;
    trigger-period-ms = <8>;      // 16
};

In both nodes the delay-ms is set to 0. But I clearly have a delay with (and only with) &msc SCRL_DOWN and &mmv MOVE_LEFT now. Could it be caused by some regression?

Sorry. Just tested it on another keyboard and the issue is most likely caused by #2042

Yep. I can confirm it now. Once I add at least one Antecedent Morph behavior to the keymap I end up with a very small delay for &msc SCRL_DOWN and &mmv MOVE_LEFT.

After some more digging I discovered that the key positions of &msc SCRL_DOWN and &mmv MOVE_LEFT in my keymap are shared with these combos:

            combo_key_repeat {
                timeout-ms = <U_COMBO_TIMEOUT>; // = 75
                key-positions = <17 18>;
                bindings = <&key_repeat>;
                require-prior-idle-ms = <U_COMBO_STREAK_DECAY>; // = 300
            };
            combo_caps_word {
                timeout-ms = <U_COMBO_TIMEOUT>;
                key-positions = <16 19>;
                bindings = <&caps_word>;
                require-prior-idle-ms = <U_COMBO_STREAK_DECAY>;
            };

And it appears that the combos are the (possibly main) contributors of these lags. But the funny thing is that the lag was non-existent even with combos until antecedent_morph_keycode_state_changed_listener started to run. So, it looks like both combos and Antecedent Morph listener contribute to these lags.

Excluding Mouse layer from global combos, like:

            combo_key_repeat {
                timeout-ms = <U_COMBO_TIMEOUT>; // = 75
                key-positions = <17 18>; 
                layers = <ENG DIK QWR>; // <-------
                bindings = <&key_repeat>;
                require-prior-idle-ms = <U_COMBO_STREAK_DECAY>; // = 300
            };
            combo_caps_word {
                timeout-ms = <U_COMBO_TIMEOUT>;
                key-positions = <16 19>;
                layers = <ENG DIK QWR>; // <-------
                bindings = <&caps_word>;
                require-prior-idle-ms = <U_COMBO_STREAK_DECAY>;
            };

completely fixes this lag. So, I guess global combos shouldn't overlap with Mouse behaviors.

[woodies11]

Did you mean mouse movement down event?