Description
Describe the Bug
So I have these keys for my home row mods:
HRM_A = LWIN_T(KC_A),
HRM_S = LALT_T(KC_S),
HRM_D = LSFT_T(KC_D),
HRM_F = LCTL_T(KC_F),
HRM_J = RCTL_T(KC_J),
HRM_K = RSFT_T(KC_K),
HRM_L = LALT_T(KC_L),
HRM_SCL = LWIN_T(KC_SCLN),
And I have the following speculative hold configuration:
#define SPECULATIVE_HOLD
#define DUMMY_MOD_NEUTRALIZER_KEYCODE KC_RCTL
#define MODS_TO_NEUTRALIZE {MOD_BIT(KC_LALT), MOD_BIT(KC_LGUI), MOD_BIT(KC_RGUI)}
Using the above keys, I am unable to trigger Shift+D on Blender. Pretty much no other shortcuts are affected, Alt+D, Shift+G, etc. works just fine.
With speculative hold disabled, the problem goes away.
To reproduce this issue locally:
- Install and open Blender
- On the splash screen, click on General under the New File column
- Press Shift+D
- Move your pointer
If the shortcut is triggered correctly, there should be a second cube following your pointer.
Some more debugging
I attempted to do further digging:
# libinput debug-events --show-keycodes | grep KEYBOARD_KEY
-event0 KEYBOARD_KEY +0.000s KEY_RIGHTSHIFT (54) pressed
event0 KEYBOARD_KEY +0.234s KEY_LEFTSHIFT (42) pressed
event0 KEYBOARD_KEY +0.348s KEY_LEFTSHIFT (42) released
event0 KEYBOARD_KEY +0.348s KEY_D (32) pressed
event0 KEYBOARD_KEY +0.349s KEY_D (32) released
event0 KEYBOARD_KEY +0.573s KEY_RIGHTSHIFT (54) released
What I suspect is happening is that the speculative KEY_LEFTSHIFT caused Blender to register the shift key as being released before KEY_D has a chance of being sent.
I uncovered a similar issue with Ctrl+F which should trigger the Face menu but it does not work with speculative hold:
# libinput debug-events --show-keycodes | grep KEYBOARD_KEY
-event0 KEYBOARD_KEY +0.000s KEY_RIGHTCTRL (97) pressed
event0 KEYBOARD_KEY +0.221s KEY_LEFTCTRL (29) pressed
event0 KEYBOARD_KEY +0.335s KEY_LEFTCTRL (29) released
event0 KEYBOARD_KEY +0.336s KEY_F (33) pressed
event0 KEYBOARD_KEY +0.337s KEY_F (33) released
event0 KEYBOARD_KEY +0.609s KEY_RIGHTCTRL (97) released
But interestingly, Alt+S does not have this problem:
# libinput debug-events --show-keycodes | grep KEYBOARD_KEY
-event0 KEYBOARD_KEY +0.000s KEY_LEFTALT (56) pressed
event0 KEYBOARD_KEY +0.339s KEY_S (31) pressed
event0 KEYBOARD_KEY +0.340s KEY_S (31) released
event0 KEYBOARD_KEY +0.538s KEY_LEFTALT (56) released
I suspect this is because my config bounds both keys to the same handedness (LALT_T(KC_S) and LALT_T(KC_L)).
Perhaps this rule could be extended to modifiers on opposite hands? So that when say, KEY_LEFTSHIFT is being held down, KEY_RIGHTSHIFT should never be speculatively triggered.
Keyboard Used
zsa/voyager
Link to product page (if applicable)
Operating System
NixOS
qmk doctor Output
Ψ QMK Doctor is checking your environment.
Ψ Python version: 3.13.12
Ψ CLI version: 1.2.0
Ψ QMK home: /tmp/qmk_firmware
Ψ Detected Linux (NixOS 26.05 (Yarara)).
Ψ Userspace enabled: False
Ψ Git branch: master
⚠ The official repository does not seem to be configured as git remote "upstream".
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 15.2.1
Ψ Successfully compiled using arm-none-eabi-gcc
Ψ Successfully tested arm-none-eabi-binutils using arm-none-eabi-size
Ψ Found avr-gcc version 15.2.0
Ψ Successfully compiled using avr-gcc
Ψ Successfully tested avr-binutils using avr-size
Ψ Found avrdude version t
Ψ Found dfu-programmer version 1.1.0
Ψ Found dfu-util version 0.11
Ψ Found diff version 3.12
Ψ Found dos2unix version 7.5.4
Ψ Found git version 2.53.0
Ψ Found make version 4.4.1
Ψ Submodules are up to date.
Ψ Submodule status:
Ψ - lib/chibios: 2025-05-15 08:25:11 +0000 -- (8bd61b8043)
Ψ - lib/chibios-contrib: 2025-10-03 18:22:15 +0200 -- (8d863d9e)
Ψ - lib/googletest: 2021-06-11 06:37:43 -0700 -- (e2239ee6)
Ψ - lib/lufa: 2022-08-26 12:09:55 +1000 -- (549b97320)
Ψ - lib/vusb: 2022-06-13 09:18:17 +1000 -- (819dbc1)
Ψ - lib/printf: 2022-06-29 23:59:58 +0300 -- (c2e3b4e)
Ψ - lib/pico-sdk: 2025-04-20 21:24:29 +1000 -- (d0c5cac)
Ψ - lib/lvgl: 2022-04-11 04:44:53 -0600 -- (e19410f8)
Ψ QMK is ready to go, but minor problems were found
Is AutoHotKey / Karabiner installed
- AutoHotKey (Windows)
- Karabiner (macOS)
Other keyboard-related software installed
No response
Additional Context
No response