[Bug] mod tap bind is chording the tap key about qmk_firmware

[sigprof]

So your problem is that your program gets the press events for Esc and j without a delay in between, even though these were separate presses?

Tap events for dual-role keys like MT() are generated when the action is determined to be a tap, which usually happens only when the key had been released, and at that time the events which happened after the dual-role key was pressed are sent without any delay in between; the only delay that would be there is the USB polling interval (USB_POLLING_INTERVAL_MS), which is 1 ms by default. So if you don't have HOLD_ON_OTHER_KEY_PRESS enabled, and the actual event sequence is

• press MT(MOD_LCTRL,KC_ESC)
• some delay
• press KC_J
• some delay (but the sum of those delays is below the tapping term)
• release MT(MOD_LCTRL,KC_ESC)

the keyboard will actually send the following events to the host when MT(MOD_LCTRL,KC_ESC) is released:

• press KC_ESC
• press KC_J
• delay for TAP_CODE_DELAY ms
• release KC_ESC

Note that there is no explicit delay between KC_ESC and KC_J, so the only delay there would be the USB polling interval (USB_POLLING_INTERVAL_MS), which is 1 ms by default, and any extra delay during processing may make that 1 ms delay effectively disappear.

As a workaround, you can try adding an extra delay in post_process_record_user():

void post_process_record_user(uint16_t keycode, keyrecord_t *record) {
    switch (keycode) {
        case MT(MOD_LCTRL,KC_ESC):
            if (record->event.pressed && (record->tap.count == 1)) {
                wait_ms(TAP_CODE_DELAY);
            }
            break;
    }
}

Maybe changing the core tapping code to insert TAP_CODE_DELAY immediately after reporting the press of the tap keycode instead of before release (as it does now) would make sense. Although there is also a special case for KC_CAPS there, which uses the larger TAP_HOLD_CAPS_DELAY, and that code also exists in 3 copies (and one more without the KC_CAPS handling)…

[XavierChanth]

I figured I would be looking at a workaround... thanks for giving me a starting point! I'll see what I come up with, although I currently see divergent branches for my board on the manufacturer's fork... so I'm hesitant to do anything until I'm sure which branch is safe to use (I would assume the most recent one with a PR open to this repo).

[XavierChanth]

Part of the issue is the latency of the keyboard, I'm able to reproduce more easily in wireless mode. However, I can reduce the chances of unintentional chording by setting chording timeouts to 0 in my shell / software, not going to bother modifying my keyboard firmware unless I absolutely have to.

Here's the changes I made to my configs for anyone curious:
bash/zsh: set keyseq-timeout 0
tmux: set -sg escape-time 0
nvim: vim.opt.ttimeout = false

[XavierChanth]

For anyone that comes across this issue in the future, I found what I was looking for here:
https://github.com/qmk/qmk_firmware/blob/master/docs/tap_hold.md#hold-on-other-key-press

I was looking for the "hold on other key press" behavior for my tap-hold bind, not the default behavior.