qmk/qmk_firmware

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

Open

#25.041 aperta il 19 mar 2025

Vedi su GitHub
 (3 commenti) (0 reazioni) (0 assegnatari)C (43.867 fork)batch import
bughelp wanted

Metriche repository

Star
 (20.368 star)
Metriche merge PR
 (Merge medio 20g 9h) (27 PR mergiate in 30 g)

Descrizione

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.

Guida contributor