#`hold-trigger-key-positions` appears to not work

1 messages · Page 1 of 1 (latest)

proud dune
#

context: I've got a keymap with home row mods, hold-preferred to allow keyboard shortcuts to trigger even if the modifier is released before the other key. This means that rolls will sometimes resolve to hold behaviors, so I use hold-trigger-key-positions to prevent the hold behavior if the keys are pressed with the same hand.

problem: Hold-tap resolves to the modifier even if the second key is on the same hand and the key presses are far shorter than tapping-term-ms. The order of events goes like this: press LSHIFT/E, press LALT/A, release LSHIFT/E, release LALT/A. All of this happens within tapping-term-ms expires (I set it to a really long time to be sure). The intended effect is lowercase E then lowercase A. The actual effect is a shifted uppercase A. This seems directly contradict the documentation which says "if you press any key not listed in hold-trigger-key-positions before tapping-term-ms expires, it will produce a tap".

Here is the behavior definition. The keyboard is a lily58.

/ {
    behaviors {
        // Home-row mods for right hand - triggers on left hand keys
        // Left hand positions: row 1 (0-5), row 2 (12-17), row 3 (24-29), row 4 (36-41)
        hmr: home_row_mod_right {
            compatible = "zmk,behavior-hold-tap";
            #binding-cells = <2>;
            flavor = "hold-preferred";
            require-prior-idle-ms = <150>;
            tapping-term-ms = <400>;
            quick-tap-ms = <150>;
            bindings = <&kp>, <&kp>;
            hold-trigger-key-positions = <0 1 2 3 4 5 12 13 14 15 16 17 24 25 26 27 28 29 36 37 38 39 40 41>;
            hold-trigger-on-release;
        };
        ...
    };
};

My understanding is that the indices of the keys matches the order they are defined in the bindings.

Any help with this issue would be greatly appreciated. Thanks in advance

desert spindle
#

Can you link your config if you have it up?

proud dune
desert spindle
#

Do you get the same behavior with balanced flavor?

#

I could suspect a docs inaccuracy with hold-preferred but pretty sure it shouldn't act this way when held for less than 400ms with balanced

#

In any case, have you tried even larger than 400ms?

proud dune
#

the behavior is fixed with the balanced flavor

#

I went with hold-preferred because I noticed that with balanced, releasing the modifier before other key would cause two key presses rather than a modified key press. changing to balanced reintroduced that issue just now

proud dune
# desert spindle In any case, have you tried even larger than 400ms?

The issue continues with hold-preferred on 1000 ms timeout. I was already sure that my keypresses were shorter than 400 ms before; now I'm even more sure the presses are within the timeout. Based on duration alone, the key presses individually should be taps (<1000 ms). Based on the fact that they overlap, the first keypress should be a hold because of hold-preferred (and it is). However, since the second keypress is not in the list of allowed keys, the first one should not be a hold