sigprof
commented
1 day ago 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 NK_ON or NK_TOGG), so that both kinds of events would be transmitted over the same shared endpoint. Another possible workaround is using KEYBOARD_SHARED_EP = yes in rules.mk (there might be some compatibility concerns though).
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:
-
19405
-
19449
Finally, you can use a workaround with a custom keycode with some extra delay added:
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
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).
hariganti
Describe the Bug
When using
S(KC_MUTE), the expected result would be:LSFTdownMUTEdownLSFTandMUTEup (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
wevThe 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