[Bug] Some keypresses get lost after quickly pressing a modded Caps Lock

[Paupa]

Describe the Bug

When typing fast, sometimes keypresses are missed after pressing a modded Caps Lock.

Example:
Keys pressed: 'Caps lock' + 'H' + 'Caps lock' + 'E' + 'L' + 'L' + 'O'
Expected output: Hello
Faulty outputs: ello, Hllo, llo

Keyboard Used

capsunlocked/cu65

Link to product page (if applicable)

No response

Operating System

Zorin OS 16.3

qmk doctor Output

Is AutoHotKey / Karabiner installed

• AutoHotKey (Windows)
• Karabiner (macOS)

Other keyboard-related software installed

No response

Additional Context

I have a quite basic keymap with just two layers that I created with the QMK Configurator. To access Layer 1, I hold the "Caps lock" key. So, internally, that key is set to LT(1, KC_CAPS_LOCK). This is a keymap that I have been trying for a week. After flashing it, I have seen that I lose letters when writing fast. I experimented a bit and found out that it is because of the "Caps lock" key.

With the keymap I had before I never had a problem with my keyboard losing keypresses.

I tried to take a peek at the code to see if I could detect where is the problem. Without having a deeper knowledge of the codebase, I think it may have something to do with the TAP_HOLD_CAPS_DELAY variable, which is set to 80 ms by default. It may be that, whenever the timer is waiting to create the specified delay, it just doesn't pick up other keypresses.

It also seems that issue #10064 might be related.

I see two possible ways:

1. This is considered a bug, as a keyboard should never miss a keypress. The code should be fixed.
2. This is considered an expected behaviour when delays are defined. I should lower or remove the delay for the "Caps lock" key. This behaviour should be documented. Currently, the Tap-Hold configuration documentation is the only reference to things happening to key events that I have found. It specifies that they are delayed but says nothing of them being lost on certain situations.

Note that until the tap-or-hold decision completes (which happens when either the dual-role key is released, or the tapping term has expired, or the extra condition for the selected decision mode is satisfied), key events are delayed and not transmitted to the host immediately.

I'll be waiting for the decision of which way you'll go to help however I can.

[sigprof]

So you are actually tapping Caps Lock while typing quickly? Then TAP_HOLD_CAPS_DELAY is applied after each such tap (the tap is detected after LT(1, KC_CAPS) is released, and then effectively the following code gets run: register_code(KC_CAPS); wait_ms(TAP_HOLD_CAPS_DELAY); unregister_code(KC_CAPS);). While wait_ms() is executed, the QMK main loop does not run, so the keyboard scanning is not performed; maybe the 80 ms delay is enough to lose a subsequent keypress in your case.

If you don't use macOS, you can lower TAP_HOLD_CAPS_DELAY to the same value as TAP_CODE_DELAY (which defaults to 0, but may need to be increased if simulated taps don't get registered properly by the host). For macOS the extra delay is required to make macOS actually recognize the tap of Caps Lock.

Maybe it could be possible to unregister Caps Lock asynchronously in this case (so that the processing of other keypresses would continue while the emulated “long tap” of Caps Lock is in progress); however, currently QMK core never does something like that (all delays are blocking, which greatly simplifies things). There could also be some concerns about changing the reported ordering of events, or maybe other delays could also interfere with the delayed release of Caps Lock.

[Paupa]

Okay, I will try removing the delay.

I have tested that if I press a letter quickly while holding my "Caps lock" key, the letter doesn't get lost but shows up delayed on my screen. I'm assuming that the delay in that case is based on the "tapping term"; the code waiting to know what action is really being performed on the "Caps lock" key. Could you tell me why the key event doesn't get lost in this case? I'm trying to look at it myself but I have no experience with C and I'm getting lost on the code constantly.

[sigprof]

The tap detection code (which is in quantum/action_tapping.c, and is probably one of the most complicated parts of QMK) does not perform any blocking delays — instead, it places incoming events in the queue (waiting_buffer) while the tap/hold detection outcome is still uncertain; so any key presses or releases done during that time are recognized normally and just get delayed.

The problematic blocking delay in your case is probably this (although there are several other instances of TAP_HOLD_CAPS_DELAY in that file, which handle other cases of Caps Lock usage, like MT(mods, KC_CAPS) or tap_code(KC_CAPS)). This delay also blocks keyboard scanning, so any key presses done during that time would be recognized only after the delay, and if you manage to release the key by that time (or the remaining press time would be less than the debounce time), the key press would be lost completely.

Apparently most people just don't use Caps Lock that frequently in the middle of quick typing, so they don't notice the issue.