Ubuntu 18.04 output delay

[CharleyShattuck]

Summary

Using keyboard protocol in Ubuntu 18.04 there is always a noticeable lag between releasing all keys and seeing output on the screen. The paper tape display is equally delayed. I had no such problem with Ubuntu 16.04, but as soon as I upgraded to 18.04 the delay was there. I'm not always fast enough to see this, but if I write continuously and quickly Plover doesn't output anything, not until I pause for a moment. Then everything I just wrote appears all at once.

Reproducing

Nothing special, just use keyboard protocol in Ubuntu 18.04.

Connected by a USB micro cable.

Plover Version

Plover 4.0.0.dev8+66.g685bd33

Plover 4.0.0.dev8+66.g685bd33

System

Linux, specifically Ubuntu 18.04,appImage, not installed. I click on the appImage on the desktop to start Plover.

[benoit-pierre]

After investigation, it's a gnome-shell bug: for some reason, the keymap layout changes (generated when using Xtest to simulate a keyboard event and when a key on the real keyboard is pressed) result in gnome-shell doing something to the X server that delays all other events for a little while (and X server high cpu usage). This can be reproduce by using xdotool to simulate input and typing on the keyboard at the same time. This does not happen with other window managers (e.g. switching back to Unity). It's also harder for me to reproduce on my real machine (as opposed to with a Virtualvox VM install of Ubuntu Bionic), whether because the machine is faster or the gnome stack is more recent, I don't know. In any case, I don't see anything actionable on Plover' side.

[mayanksuman]

My configuration is a bit different. OS: Debian Linux ((kernel version: 4.19.0-2-amd64) WM: Gnome (3.30.2)

However, plover (commit 2943a97) is also showing lag in the input. I observed that upon fast typing Xorg process start to consume full cpu till all the words appear on the screen.

I tried to use plover on wayland too, but it is not working there (issue #1050). Hence, combined with this issue the plover is having problem with keyboard input in Gnome WM on both mode (Xorg and Wayland).

[zapakh]

I'm running XFCE4 (xubuntu 20.04), no Gnome in sight, and having the same problem. It's not just output that slows down. Video and anything else that's running tends to stutter, too. Running xev -event keyboard shows a lot of events like

MappingNotify event, serial 285, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 8, count 248

while running Plover. There are two such events per chord, one at the time of the first keydown and another at the time of the last keyup.

It seems related to this report:

https://bugs.launchpad.net/ubuntu/+source/meta-gnome3/+bug/1777708

I get the same kind of behavior without Plover if I try to type on two USB keyboards. Also, the Sidewinder X4 keyboard, which plugs in via USB and performs NKRO beyond the usual 6-key limitation exhibits the problem whenever I press more than 6 keys.

However, now that I'm plugged in via PS/2 and using only one keyboard, I only see the MappingNotify events and the accompanying slowdown while Plover is running and enabled.

Using the PLOVER:TOGGLE chord to enable Plover causes only one MappingNotify event to be emitted, when I release the chord and Plover enables. Using the same chord to disable Plover causes only one MappingNotify event, at keydown time.

It seems like this might be a bug or a design flaw deep inside X somewhere, but it seems to have only appeared, in Ubuntu distributions at least, a few years ago. I'm at a loss for any kind of a workaround, beyond maybe running Plover on a completely different machine and using a tool like x2x to inject text into applications.

[zapakh]

I have a partial workaround. It seems that the troublesome MappingNotify events are only generated when there is inputs from different slave devices under the same master.

If you use xinput create-master to create a new master device, and then xinput reattach to put your hardware keyboard (I should say, one of your keyboards) under the new master, then Plover can still receive chords from it, and the output is emitted via Virtual core XTEST keyboard under the original Virtual core keyboard master, which doesn't generate the flurry of MappingNotify events because X isn't processing events from multiple devices under the same master.

The drawback, of course, is that your keyboard is now associated with a new master pointer device, as indicated by the second mouse cursor that appeared when you did xinput create-master so the keystrokes that "bypass" Plover (such as when Plover is disabled, or when you're pressing a modifier key or using keys outside Plover's purview) aren't going to go where you want them to, at least not unless you put a second mouse under the new master pointer device and click in your application window with that, too.

In practice, I use the other keyboard for Plover-bypass stuff. It generates MappingNotify events and lag when I switch, but at least it doesn't happen with every stroke.

I don't know if any of this informs a workaround that can be incorporated into the X-specific oslayer stuff in Plover, but at least it might help a few people out of a jam if they run into the same problem.

[landermkerbey]

I was experiencing similar issues earlier, but I found that switching from X to Wayland has so far made the problem disappear for me. Plover is now outputting text for me in emacs as snappy as you please. I followed these instructions.

[user202729]

For the workaround part, I guess it's possible to reattach all the keyboards to the new master device when Plover is enabled, then move them back when Plover is disabled.

I don't think this should be the default however, it may have other issues. (my window manager crashes occasionally when I use the workaround, I think?)

Also would be nice if it handles newly attached keyboards, although this one is a different issue.

.note. I don't know how to reattach/create master from the API other than calling the subprocess. Need to read more documentation.

---

Actually, making the keyboard floating would work too (that way it isn't even necessary to grab, although the turn-on PHROLG will mistakenly delete 6 characters)

---

Correction: if the keyboard is already floating, Plover grab will fail.

X protocol error:
<class 'Xlib.error.BadValue'>: code = 2, resource_id = 0, sequence_number = 17, major_opcode = 131, minor_opcode = 46

So... need some Plover integration for this approach to work.

[opensourcefiction]

I am also experiencing a significant delay that's noticeable even though I'm just learning and not writing faster than 16-18 WPM while practicing on Typey Type. I'm already faster than the output displayed, sometimes by four or five words.

Pureos 10 Gnome 3.38.5 (Gnome classic, no Wayland) Plover Plover 4.0.0.dev8 (installed from Pure OS repo) Plover 4.0.0.dev12 (appimage) Xorg Version: 1:7.7+22