[Bug] Some keypresses get lost after quickly pressing a modded Caps Lock
#25,041 建立於 2025年3月19日
倉庫指標
- Star
- (20,368 star)
- PR 合併指標
- (平均合併 20天 9小時) (30 天內合併 27 個 PR)
描述
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:
- This is considered a bug, as a keyboard should never miss a keypress. The code should be fixed.
- 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.