Sleep delay after Unicode keystrokes

[RedBearAK]

Some combination of virtual machine input and/or issues with ibus or general input on KDE Plasma causes partial failures of Unicode keystrokes sequences. Symptoms include leaving the underlined "u" from the Shift-Ctrl-u combo, or leaving portions of the Unicode address on the screen, rather than successfully creating the Unicode character.

When this problem occurs, the key sequences that follow after will not work as expected. The Unicode sequence acts like it has been interrupted or stuck in some buffer waiting for further input.

Also, when the issue is happening it affects almost 100% of the attempts to use the Unicode keystrokes function. It is very repeatable.

Minimum sleep delay that fixes this problem reliably is about 0.1s (1/10s), inserted after the Enter key keystroke that finishes the Unicode sequence. The delay makes no obvious difference in how quickly a Unicode character can be created, but restores the reliable use of Unicode sequences in macros.

Changes

Checklist

• [ ] Added tests (if necessary)
• [ ] Updated docs or README...

[joshgoebel]

Until we fully understand this and are certain there is no other fix (or chance of a fix) I'd rather this sort of thing not leak into core. 1/10s is a fracking LONG time... This would be an easy thing to document on the wiki and someone could just copy the modified function into their local config if they were running into this issue.

I still imagine there is a fix to be found here somewhere since these MAJOR timing pauses really should not be necessary at the very low-level we're functioning at. I wonder if we could ask some other keymapper projects?

[RedBearAK]

@joshgoebel

1/10s is a fracking LONG time

In a lot of contexts that would be true, but… I've described before how I can literally see the keystrokes being "typed" when I use macros, and the same holds true for the Unicode sequence. I can see it typing out the Unicode address very briefly before it hits Enter to finish the sequence and create the Unicode character. So in my testing, this short delay makes no obvious difference to the usage of keyszer overall.

I wonder if we could ask some other keymapper projects?

Until I do more bare-metal testing I would have no idea what to even ask other keymapper project devs. Not sure if the problem is my laptop, the VM input, or KDE not behaving nicely with ibus.

None of this has ever been an issue with GNOME (so the problem is unlikely to just be my laptop hardware). But without this patch I suspect my Option-key special character entry scheme will be completely unusable in KDE setups.

could just copy the modified function into their local config if they were running into this issue

That is one possible solution. But, I don't think this patch produces any practical harm in core while I look for something better. It won't do anything at all unless the user is producing Unicode characters.

I suppose if you're on hardware where you've always seen the macros and Unicode function operating so fast that they appear to be instantaneous, you may have a different perspective on how slow a tenth of a second is. But in my experience it's a meaningless delay in this context, with the huge upside of making the function reliable.

Rest assured I will keep trying to understand the root cause and will keep looking for a better solution.

[joshgoebel]

So in my testing, this short delay makes no obvious difference to the usage of keyszer overall.

The problem is needless delays... the fact that timing issues only happen in some environments means you're slowing everyone down - even those whose setups don't have such problems. I'm not willing to do that - esp. not before the problem is even fully understood. I treat this as low-level software - it should be super responsive... if you trigger a combo then hit another key that should register as soon as possible... which means that extra 1/10s delays don't really make sense.

Once you add these kind of things they tend to never come back out - since no one fully understands why they were added - it's often impossible to prove they are "safe" to remove.

I'm tempted to suggest config knobs, but I imagine before you're done you'll have more than a few different timing knobs and that gets messy... I'm open to one or two timing knobs if they would help make this problem go away by turning it into a config issue... but we'd need to carefully identify where to put them first.

[joshgoebel]

Also I do lean heavily on how easy Python is to extend to push back against things that I don't think are fully baked yet. It'd be pretty easy for you to publish your own "delayed" extensions as just a single file someone could require... a one liner at the top of their config that adds delays all sorts of places.

I think keyszer is more of a "come and learn, and built your config from scratch" kind of software that people will build things on top of (like kinto.sh). So I'd like to make "hacks" for one particular desktop environment optional rather than mandatory.

[RedBearAK]

I was already thinking of maybe implementing a tunable knob setting for this problem, like the suspend timeout knob. But I think I'll save that possible solution for after I do some further testing and verify my theory that it's mainly KDE being uncooperative with ibus. Unfortunately there doesn't seem to be any other easy way to get to the Unicode characters by just "typing".

The worst possible solution was adding the sleep delay to hundreds of output lines in my Option-key special character scheme config file. I tried that on a few lines, which was how I figured out that a short delay after every UC(0000) was what would fix the strange behavior.

If I get more insight into what is going on and how widespread the issue is, I'll revisit this. I'll close and make a new PR if I find a better solution, but I'd like to leave it open for now.

[joshgoebel]

The worst possible solution was adding the sleep delay to hundreds of output lines in my Option-key special character scheme config file.

Of course you'd do this with a function in a single place, not by modifying 100 lines...

[RedBearAK]

@joshgoebel

I seem to have found a different solution (and possibly the cause) for this issue. Removing the sync line in output.py, in the send_key_action function appears to fix this and other things (macro reliability in general).

Closing this.