-
-
Notifications
You must be signed in to change notification settings - Fork 39.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug] Shifted media keys appear to send the media key first and shift second, rather than the correct order #24612
Comments
The problem is probably caused by the modifiers and media key events being sent over different USB endpoints, therefore the relative ordering of those events is not well defined (QMK just queues both reports, and the host may poll those USB endpoints in any order). You can try enabling NKRO (note that it needs to be turned on with Also there were some PRs trying to work around the lost modifier issue commonly happening with RDP, which may help here too (by adding a delay between reporting the modifiers and the modified key); however, those PRs are not merged yet: Finally, you can use a workaround with a custom keycode with some extra delay added:
You should be able to do something like if (record->event.pressed) {
register_code(KC_LSFT);
wait_ms(2);
register_code(KC_MUTE);
} else {
unregister_code(KC_MUTE);
wait_ms(2);
unregister_code(KC_LSFT);
} (although the extra delay at release time might be unneeded). |
Thanks for the added context. Do you know if the shared endpoint option is also part of the JSON data-driven config yet? I might try that first and revert to using a delay (didn't know that function existed) if there are compatibility issues. I can set up a |
|
I currently use my |
Using a shared endpoint with the configuration option (didn't test with NKRO) didn't seem to work, but adding a delay of 5 ms--arbitrarily chosen--at keydown works well. I'm not sure if this issue should then be closed since a workaround is still required, and something like an optional mod delay, as a |
Describe the Bug
When using
S(KC_MUTE)
, the expected result would be:LSFT
downMUTE
downLSFT
andMUTE
up (in any order)However, it appears that the order is reversed for the media keys, where the media key is pressed first and the shift is pressed second, according to the output from
wev
The red box shows regular media key usage and the green box shows where
S(KC_<MEDIA_KEY>)
was used insteadKeyboard Used
No response
Link to product page (if applicable)
No response
Operating System
Ubuntu 24.04 with Linux 6.8.0-48-generic
qmk doctor Output
Is AutoHotKey / Karabiner installed
Other keyboard-related software installed
No response
Additional Context
On a macropad (DOIO 16-key with triple encoder) with configuration using Via, this doesn't seem to be an issue. Configuring an encoder to send
S(KC_MUTE)
works as expected.My current workaround is a custom keycode handler that sends shift at keydown and taps the media keycode before releasing shift at keyup. The issue is that this means I can't hold the key to repeat the action
The text was updated successfully, but these errors were encountered: