Caps Lock injections being unreliable (?) lately #1219
Description
So, I've been a long time user of input remapper for some basic functionality and keyboard macros,
but even more recently I've managed to figure out a very nice macro setup to efficiently work around an infamous quirk of X11's XKB (which is still what is used in Wayland) and how it implements Caps Lock - described by many who use Caps Lock for capitalization rather than Shift (yes, we exist) as the "CAps LOck DElay", because as it is by default, it behaves in a way simulating old typewriters, which is different from how it behaves in Windows (which I was more used to)
to summarize, with XKB, if Caps Lock is off, just pressing it turns it on immediately. if Caps Lock is on, and then you press it, then it is STILL on while you are keeping it held, and only turns it off after you release it. So the behavior is different depending on the state. On Windows, since the MS-DOS days, it is always toggled on Press, rather than release, both when it's on, and when it's off. Windows Users that used Caps Lock the same way I do were put off by most Linux distros that employ XKB perceiving a "delay" when typing, because we would type fast enough that we'd press a letter key *before we finished releasing Caps.
there are some solutions being proposed for XKB configs in the 2.0 config format but there doesn't seem to be any distro that has those implemented just yet, so I have to settle with the workarounds in the meantime.
and there is also a widespread "workaround" script that just virtually holds shift whenever you press Caps Lock while it's on, but that introduces a Separate issue/side effect where now you may accidentally type symbols instead of numbers, not to mention the Caps Lock LED didn't match, so I didn't like it as much.
with input remapper I was able to basically somewhat "solve" the issue at the source - now the Actual Caps Lock is toggled whenever pressing it no matter the state of the lock.
I achieved this by setting a macro for Caps Lock with the following command:
key_down(Caps_Lock).key_up(Caps_Lock)
it just presses the key, then immediately releases it - every time that the physical button is pressed.
This not only worked EXACTLY as I was expecting, but even the LED on the key itself was turning on and off, so I knew it was working, and was pretty happy with the result.
Previously I had a wait command in between the key_down and key_up ones set to 1 millisecond, but it seems it wasn't really needed, and it still worked without it. That said, with the new issue I'm having now, maybe that would be something I'd have to revisit.
so what's happening now after some time using it is, sometimes it is just not triggering it, randomly.
Whenever I start up my system (Kubuntu), it would usually work right away, but now, it seems like it takes a short while for it to work. I press it, and the LED doesn't light up. Press it again a bunch more times and nothing, until eventually it does, and starts working as I expect. But then later as I'm just typing normally, it will happen again for a brief moment - pressing will not toggle, so I have to press again, sometimes more than once, then it's back to normal, until it happens again, rinse and repeat.
Don't know if it was an update to the software that is causing this, if waiting a few milliseconds as I was doing originally would account for this, or anything else, but I definitely would appreciate to be pointed any direction that could help... if anyone believes that for my particular use case I would be better off with a different software rather than input remapper for any reason (efficiency, speed, reliability, etc), then I would like to know as well.
Thanks in advance!