Failures in output without adding sleep delays #187
Comments
|
possibly related: sezanzeb/input-remapper#335 |
Yes, that does seem very similar. Thanks for the link. Due to the differences between the projects I'm not sure exactly how the delay I put in that location in keyszer compares. I notice someone says they need to use a delay of 20ms, which is close to the 0.05s (50ms) I'm needing to use in this VM situation. Unfortunately the way I'm inserting the delay doesn't just affect "macros" but all keystrokes, which means it adds the delay even during normal typing. But I can't seem to make transformed shortcut combos work correctly without the delay. No one in that thread seems to have any idea exactly what is causing the issue, just that adding a delay is a workaround. |
|
Output from the virtual keyboard appears perfect, pressing Shift before the correct keystrokes and releasing Shift after the other key is pressed/released. But what winds up in the text editor without the long delay is variations of: When it should be:
|
|
This issue should probably be reported at one of gnomes issue trackers https://gitlab.gnome.org/GNOME, considering you specifically have problems with gnome (#186 (comment)), but I don't know which project would be fitting for that. |
No, I have had problems with these key sequence unreliability issues in multiple distros, multiple DEs and now, multiple display servers (X11 and Wayland). As far as I know there is nothing about this specific to GNOME. The problem just seems to be quite a bit worse within a couple of the VMs I'm testing. But the host OS is Fedora/X11/GNOME while the VMs are Kubuntu/X11/Plasma and Ubuntu/Wayland/GNOME. I've also replicated the issue of unreliable macros on other laptops of varying descriptions. Most were less prone to the problem than the Acer laptop I'm usually working on, but it happened on all of them if I tested enough times. Different Linux distros, different desktop environments, different hardware. If I had a proper concept of what exactly is "receiving" the keystrokes from the virtual keyboard when it's "typing", I might have some idea what direction to go with researching a solution. Is it the kernel input system, or the display server, or the window manager, or the application window itself? Where in the chain might there be some kind of buffer that is mixing up keystrokes, or even losing some of them, when they are issued too quickly? |
|
Do you observe the issue in |
I'll have to get back to you on that. The But maybe I can get it to work better on the host, in X11. Will update tomorrow if I have time. Edit: No, this is the first time I've seen an app in X11 fail to report any WM_CLASS and WM_NAME from using |
|
Preliminary results appear to be the same as with I'll have to do some filtering of the Edit: No apparent problem with the filtered |
https://gitlab.freedesktop.org/libinput/libinput So I guess libinput is not the issue, since X11 seems to work fine? But maybe it could be worth asking for more directions there The arch wiki mentions |
|
Update: Someone left a note on the IBus does seem to play a large part in the severity of the problem I'm experiencing in the VM, which takes delays of around 100ms in total to have predictable output appear in the application. But, macros will still fail even when IBus is disabled. Although it only takes 1ms of strategic keystroke delay in order to bring back macro reliability. So the problem requires two orders of magnitude more "correction" with IBus involved, but still occurs and needs some correction without IBus being involved. |
I see by the existence of issue #101 (still open as of now), that more than one person has had issues with key presses being missed. I've been kind of dealing with a related problem for a long time, which is that in some situations there seems to be an issue with output from the virtual keyboard suddenly stopping or having gaps.
Adding a sleep delay at certain points in the app I'm using (a keymapper called keyszer, forked from xkeysnail), will almost completely cure this behavior, but not entirely. And the delay in some situations (virtual machines) needs to be so long that it makes the keymapper pretty unusable.
Hoping someone has some insight here on why this kind of thing might happen, and how it might be cured.
Here's an example of what happens. The keymapper can see an input combo and transform it into some other combo, or even a string of characters (including Unicode in various forms) into a set of output keystrokes. So I can set up CapsLock as a hotkey to output the string "You have pressed CapsLock!" into a text editor app window.
But when this problem is occurring, I'll get various kinds of mistakes in the output like:
You have pres
You have pressed CapsLock1
You have preCapsLock!
And so on. Just kind of random glitches in what is supposed to be getting "typed" by the virtual keyboard.
Many users of these keymappers never seem to encounter these issues. I seem to encounter them a lot more frequently. Especially in virtual machines, where I've had pretty bad problems with Kubuntu/KDE/X11 and even worse with Ubuntu/GNOME/Wayland.
The problem is not in the creation of the list of keystrokes that the keymapper returns and sends to the virtual keyboard. I can see all the intended keystroke events being logged to a terminal. I can print out the list of keystrokes before they are sent to the output module, and it's always perfect. Some of the keystrokes just seem to vanish and never come out into the focused app window.
One particular spot that has been helpful in reducing this is this function that sends a sync:
On my main laptop with a bare metal install, this delay only needs to be 0.0001s to be useful. In the VM I'm testing, it needs to be about 0.05s, or things start to go wrong with the output.
Any ideas anyone has to troubleshoot this would be helpful. I've tried to work with the keyszer dev to understand exactly what is going wrong and how to mitigate it, but we've never made much progress.
https://github.com/joshgoebel/keyszer
The text was updated successfully, but these errors were encountered: