qmk/qmk_firmware

[Bug] Speculative hold breaks Blender shortcuts

Open

#26061 opened on Mar 12, 2026

View on GitHub
 (2 comments) (0 reactions) (0 assignees)C (20,368 stars) (43,867 forks)batch import
bughelp wanted

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:

  1. Install and open Blender
  2. On the splash screen, click on General under the New File column
  3. Press Shift+D
  4. 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)

https://www.zsa.io/voyager

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

Contributor guide