zmkfirmware / zmk

ZMK Firmware Repository
https://zmk.dev/
MIT License
2.82k stars 2.85k forks source link

Feature request: add tap-ms property to hold-tap behavior #1443

Open manna-harbour opened 2 years ago

manna-harbour commented 2 years ago

Hold-tap taps are sent as press immediately followed by release. This can cause compatibility issues with other systems.

QMK has TAP_CODE_DELAY for this purpose, default 100ms, https://github.com/qmk/qmk_firmware/blob/master/docs/config_options.md#behaviors-that-can-be-configured.

The macros behavior has a tap-ms property, implemented with behavior_queue, default 100ms, https://zmk.dev/docs/behaviors/macros#tap-time.

Hold-tap could be implemented using behavior_queue with tap-ms in the same way as in the macros behavior.

It might also be necessary to do this with all behaviors that generate key events, such as shifted keycodes in kp. See https://github.com/zmkfirmware/zmk/issues/756, https://github.com/zmkfirmware/zmk/issues/759, https://github.com/zmkfirmware/zmk/issues/815,

lesshonor commented 1 year ago

...probably worth noting that QMK's default for this value is actually 0

(a lot of projects began setting it to 10ms because supposedly Windows ignores volume up and down events sent more quickly than that, but 100ms would be quite noticeable)

caksoylar commented 1 year ago

The default tap time of macros has been changed to 30ms since then, but that is probably still a bit long outside of remote desktopping and such.

Now that there are parametrizable macros, this could be worked around easier using them instead of &kp:

        kpt: kp_tap_time {
            compatible = "zmk,behavior-macro-one-param";
            label = "KPT";
            tap-ms = <10>;  // tweak as needed
            #binding-cells = <1>;
            bindings = <&macro_param_1to1>, <&kp MACRO_PLACEHOLDER>;
        };

Then using &kpt instead of &kp in the hold-tap definition.