rvaiya
Unexpected behavior when overloading capslock as meta / esc
i first noticed this when attempting to play some old school classic Doom, and when tapping capslock to use as escape to open the menu, the menu would open and then immediately close again, every time i tapped the key. it opened and stayed open normally when tapping the actual escape key.
with the following default.conf file:
[global]
disable_modifier_guard = 1
[ids]
*
[main]
capslock = overload(meta, esc)
i would expect that a single tap of capslock would then simply emit escape down and then up, and when holding it down as a modifier it would emit the meta down and up events. but when holding it down, it initially emits only meta down, as expected, but upon release, it then also emits unexpected escape down and up events at the end.
(i disabled modifier guard as per your suggestion in the other issue, but i now don't think it has anything to do with what i'm experiencing, since it's still happening, whether modifier guard is enabled or disabled)
output from testing with sudo keyd monitor, during which i only held down capslock key for about a second as if i were using it as meta, and then released it, after which i pressed ctrl+c to exit:
device added: 1532:0084:288cfcd8 Razer Razer DeathAdder V2 (/dev/input/event10)
device added: 1532:0084:6cf24928 Razer Razer DeathAdder V2 Keyboard (/dev/input/event8)
device added: 1532:0084:19ad785d Razer Razer DeathAdder V2 (/dev/input/event7)
device added: 0fac:1ade:d2b36ae6 keyd virtual pointer (/dev/input/event28)
device added: 0fac:0ade:efba1ddf keyd virtual keyboard (/dev/input/event27)
device added: 27c6:01e0:bdc0a1f0 GXTP5100:00 27C6:01E0 Touchpad (/dev/input/event26)
device added: 27c6:01e0:c56bcc82 GXTP5100:00 27C6:01E0 Mouse (/dev/input/event25)
device added: 0000:0006:bdb72f48 Video Bus (/dev/input/event12)
device added: 0000:0006:bdb72f48 Video Bus (/dev/input/event11)
device added: 048d:c998:193096a7 ITE Tech. Inc. ITE Device(8258) Keyboard (/dev/input/event4)
device added: 0001:0001:70533846 AT Translated Set 2 keyboard (/dev/input/event3)
keyd virtual keyboard 0fac:0ade:efba1ddf enter up
keyd virtual keyboard 0fac:0ade:efba1ddf leftmeta down
keyd virtual keyboard 0fac:0ade:efba1ddf leftmeta up
keyd virtual keyboard 0fac:0ade:efba1ddf esc down
keyd virtual keyboard 0fac:0ade:efba1ddf esc up
keyd virtual keyboard 0fac:0ade:efba1ddf leftcontrol down
keyd virtual keyboard 0fac:0ade:efba1ddf c down
Ah - the behaviour you see with Doom is actually the reason why modifier guards are enabled by default (but it evidently does not work for Doom). That is: I assume that Doom takes an action immediately upon keydown of the modifier, which messes with keyd's approach of eager activation and subsequent cancellation.
This is also seen in issue #364 and I would suggest the same approach: use overloadt with a small timeout.
In the other issue you wrote:
even when holding the key down and using it as meta, after releasing it emits not only meta up, but also escape down and up.
To be clear: with 'using it as meta', do you mean 'holding down capslock while overlapping with another key'?
Keep in mind that overload on its own is not time-based; the only distinction between the hold and tap action is whether it overlaps with another key. Your example here suggests that you would expect a longer hold time to resolve as meta even without overlapping keypresses; use something like timeout(overloadt(meta, esc, 150), 150, layer(meta)) to achieve that.
On June 14, 2025 11:46:46 PM GMT+02:00, alefnull @.***> wrote:
alefnull created an issue (rvaiya/keyd#1038)
i first noticed this when attempting to play some old school classic Doom, and when tapping capslock to use as escape to open the menu, the menu would open and then immediately close again, every time i tapped the key. it opened and stayed open normally when tapping the actual escape key.
with the following
default.conffile:[global] disable_modifier_guard = 1 [ids] * [main] capslock = overload(meta, esc)i would expect that a single tap of capslock would then simply emit escape down and then up, and when holding it down as a modifier it would emit the meta down and up events. but when holding it down, it initially emits only meta down, as expected, but upon release, it then also emits unexpected escape down and up events at the end.
(i disabled modifier guard as per your suggestion in the other issue, but i now don't think it has anything to do with what i'm experiencing, since it's still happening, whether modifier guard is enabled or disabled)
output from testing with
sudo keyd monitor, during which i only held down capslock key for about a second as if i were using it as meta, and then released it, after which i pressed ctrl+c to exit:device added: 1532:0084:288cfcd8 Razer Razer DeathAdder V2 (/dev/input/event10) device added: 1532:0084:6cf24928 Razer Razer DeathAdder V2 Keyboard (/dev/input/event8) device added: 1532:0084:19ad785d Razer Razer DeathAdder V2 (/dev/input/event7) device added: 0fac:1ade:d2b36ae6 keyd virtual pointer (/dev/input/event28) device added: 0fac:0ade:efba1ddf keyd virtual keyboard (/dev/input/event27) device added: 27c6:01e0:bdc0a1f0 GXTP5100:00 27C6:01E0 Touchpad (/dev/input/event26) device added: 27c6:01e0:c56bcc82 GXTP5100:00 27C6:01E0 Mouse (/dev/input/event25) device added: 0000:0006:bdb72f48 Video Bus (/dev/input/event12) device added: 0000:0006:bdb72f48 Video Bus (/dev/input/event11) device added: 048d:c998:193096a7 ITE Tech. Inc. ITE Device(8258) Keyboard (/dev/input/event4) device added: 0001:0001:70533846 AT Translated Set 2 keyboard (/dev/input/event3) keyd virtual keyboard 0fac:0ade:efba1ddf enter up keyd virtual keyboard 0fac:0ade:efba1ddf leftmeta down keyd virtual keyboard 0fac:0ade:efba1ddf leftmeta up keyd virtual keyboard 0fac:0ade:efba1ddf esc down keyd virtual keyboard 0fac:0ade:efba1ddf esc up keyd virtual keyboard 0fac:0ade:efba1ddf leftcontrol down keyd virtual keyboard 0fac:0ade:efba1ddf c down-- Reply to this email directly or view it on GitHub: https://github.com/rvaiya/keyd/issues/1038 You are receiving this because you are subscribed to this thread.
Message ID: @.***>
Ah - the behaviour you see with Doom is actually the reason why modifier guards are enabled by default (but it evidently does not work for Doom). That is: I assume that Doom takes an action immediately upon keydown of the modifier, which messes with keyd's approach of eager activation and subsequent cancellation.
ohhh, yeah that would definitely be the issue. i know John Carmack is almost militant in his belief in the "act on press" paradigm / way of doing things. that explains it.
Keep in mind that overload on its own is not time-based; the only distinction between the hold and tap action is whether it overlaps with another key. Your example here suggests that you would expect a longer hold time to resolve as meta even without overlapping keypresses; use something like timeout(overloadt(meta, esc, 150), 150, layer(meta)) to achieve that.
ahhh that would certainly make sense, and i feel a bit silly for not considering that possibility.
i have actually tried playing with overloadt instead, with varying delay times, but haven't really found anything that "feels right", if you will. but that's entirely a "me" problem.
thanks for the insight and answers. feel free to close this. and apologies, again, for taking up more of your time.
i have actually tried playing with overloadt instead, with varying delay times, but haven't really found anything that "feels right", if you will. but that's entirely a "me" problem.
I have found the same for myself in terms of timeouts.
A case could be made for making eager activation entirely configurable, or at least making overloadt() not emit the modifier down/up events before executing the tap action. Would you find practical value in that?
thanks for the insight and answers. feel free to close this. and apologies, again, for taking up more of your time.
No worries at all!
A case could be made for making eager activation entirely configurable,
i'll be honest i'm not 100% sure i'm following what you're suggesting. what do you mean by "eager activation"?
or at least making overloadt() not emit the modifier down/up events before executing the tap action. Would you find practical value in that?
do you mean making it so if i held down the key, it would basically emit nothing until either another key was pressed or until it's let go?
EDIT: as a note, i've been trying out overloadt() with a delay of 150ms, and while it's not perfect and i've mis-timed some keypresses here and there, it's been working out pretty decently so far.