Sticky keys repeat indefinitely unless if pressed again

[Leonardo Müller]

It was noticed that, when using QEMU, keys pressed when using the guest can get stuck and repeat indefinitely. To undo that, the particular key has to be pressed again. While what is the key currently stuck can be obvious when it is a letter or number, Ctrl or even Enter can get stuck, which can lead to confirming doing dangerous actions in the guests (think replacing multiple files with a GUI file manager).

A command as simple as:

qemu-system-x86_64 -accel kvm -m 1536 -vga qxl -cdrom xubuntu-18.04.3-desktop-amd64.iso

Is triggering the bug. I tried using the workaround using -device usb-kbd but that didn't solve. It's currently being hard to use QEMU due to this bug.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: qemu-system-x86 1:4.0+dfsg-0ubuntu10
ProcVersionSignature: Ubuntu 5.4.0-9.12-generic 5.4.3
Uname: Linux 5.4.0-9-generic x86_64
ApportVersion: 2.20.11-0ubuntu15
Architecture: amd64
CurrentDesktop: XFCE
Date: Mon Jan 13 23:38:56 2020
InstallationDate: Installed on 2017-06-13 (944 days ago)
InstallationMedia: Xubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
KvmCmdLine:
 COMMAND STAT EUID RUID PID PPID %CPU COMMAND
 qemu-system-x86 Sl+ 0 0 33485 33480 22.7 qemu-system-x86_64 -accel kvm -m 1536 -cpu Skylake-Client -device nec-usb-xhci -device usb-host,id=cruzerblade,vendorid=0x0781,productid=0x5567 -bios /usr/share/ovmf/OVMF.fd -vga qxl -cdrom /home/usuario/Sistemas/xubuntu-18.04.3-desktop-amd64.iso -device usb-kbd
 kvm-nx-lpage-re S 0 0 33490 2 0.0 [kvm-nx-lpage-re]
 kvm-pit/33485 S 0 0 33494 2 0.0 [kvm-pit/33485]
MachineType: LENOVO 80UG
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-9-generic root=UUID=6b4ae5c0-c78c-49a6-a1ba-029192618a7a ro quiet ro kvm.ignore_msrs=1 kvm.report_ignored_msrs=0 kvm.halt_poll_ns=0 kvm.halt_poll_ns_grow=0 i915.enable_gvt=1 i915.fastboot=1 resume=UUID=a82e38a0-8d20-49dd-9cbd-de7216b589fc log_buf_len=16M usbhid.quirks=0x0079:0x0006:0x100000 config_scsi_mq_default=y scsi_mod.use_blk_mq=1 mtrr_gran_size=64M mtrr_chunk_size=64M nbd.nbds_max=2 nbd.max_part=63
SourcePackage: qemu
UpgradeStatus: Upgraded to focal on 2019-12-22 (22 days ago)
dmi.bios.date: 08/09/2018
dmi.bios.vendor: LENOVO
dmi.bios.version: 0XCN45WW
dmi.board.asset.tag: NO Asset Tag
dmi.board.name: Toronto 4A2
dmi.board.vendor: LENOVO
dmi.board.version: SDK0J40679 WIN
dmi.chassis.asset.tag: NO Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Lenovo ideapad 310-14ISK
dmi.modalias: dmi:bvnLENOVO:bvr0XCN45WW:bd08/09/2018:svnLENOVO:pn80UG:pvrLenovoideapad310-14ISK:rvnLENOVO:rnToronto4A2:rvrSDK0J40679WIN:cvnLENOVO:ct10:cvrLenovoideapad310-14ISK:
dmi.product.family: IDEAPAD
dmi.product.name: 80UG
dmi.product.sku: LENOVO_MT_80UG_BU_idea_FM_Lenovo ideapad 310-14ISK
dmi.product.version: Lenovo ideapad 310-14ISK
dmi.sys.vendor: LENOVO
mtime.conffile..etc.apport.crashdb.conf: 2019-08-29T08:39:36.787240

[Christian Ehrhardt  (paelzer)]

Hi Leonardo,
I've not heard about that behavior before nor seen it myself.
I booted y xubuntu iso but to me it seemed to behave normal.

What exactly are you doing to trigger it being stuck.
E.g. open a console in the guest and hold "A" for 3 seconds?
For me that entered some "A" chars until I let go (plus some overhang for inputs already queued but taking a while to be processed, but not much maybe half a second)

[Leonardo Müller (leozinho29-eu)]

To trigger this bug, I just write some text and then some key can get stuck. However, there is one reliable way to trigger this bug: hold the key for long enough it would be right before starting repeating the key on Mousepad (considering using Xubuntu ISO as the guest). If release with the right timing, that specific key will get stuck.

The attached video shows the bug being triggered using onboard.

[Christian Ehrhardt  (paelzer)]

Your video is very convincing :-)

For the sake of not giving up I again stated the xubuntu iso, opened the mousepad editor just like you and typed about two pages of silly charcters.

It never got stuck the way I see it in your video.

Unfortunately (sorry) all I can say is:
a) you could try newer versons soon (qemu/libvirt will be bumped in a week or two I hope) in 20.04
b) I tried the qemu 4.0 you used but on a Bionic system, did you by any chance have a try on that if it might be related to the Host Desktop Environment?
c) you might report that to upstream just in case anyone in the wider community might have seen that behavior before

[Leonardo Müller (leozinho29-eu)]

I did some testing with the openbox session and noticed this problem isn't happening on it, even tried with onboard too. It happens on Xfce (both 4.12 an 4.14 were tested, as I was using Bionic before the upgrade). I would have to install other desktop environments to test, but I'm afraid one environment can cause problems in the other.

[Bryce Harrington (bryce)]

Ah, I am pretty sure I recognize this. The symptoms and behaviors match an ancient and well known X11 bug that I dug into some years ago, and you can read my findings in comment #310 of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406.

The sticky repeat is due (as I understood it -- this is a bit speculative) to a race condition in tracking and updating the key down and up states. The issue tends to be hard to reproduce when you do have it, and hard to get rid of when you do, because triggering the misbehavior depends on several low level components stepping on each others' toes at just the right time to lose the keyup -- or something like that. If you're lucky, sometimes just randomly upgrading or downgrading one of these components (or switching keyboards, reinstalling things, etc.) can be enough to get the timings desynchronized (or whatever). This might explain why there are so many claimed "solutions" by forum posters and bug comments, that rarely seem to work for anyone but that one guy, and why the problem keeps cropping up in random situations.

I'd thought at the time maybe Wayland would finally solve this, however I've seen scattered reports of people seeing the same problem there, so maybe it's just one of those oddball unsolvable bugs.

A commonly used workaround is to disable keyboard repeat, either in GNOME settings, or via xset r rate (see man xset, and note you may need to re-run xset periodically).

[Leonardo Müller (leozinho29-eu)]

I was able to test on Mate and the same problem was observed: sticky keys with the right timing to release the keys.

It also seems independent from the guest, even a Windows 10 guest was affected by this bug.

[Bryce Harrington (bryce)]

Did disabling autorepeat help at all?

[Leonardo Müller (leozinho29-eu)]

Yes, disabling key repeat on xfce4-keyboard-settings in the host makes the problem stop happening.

[Leonardo Müller (leozinho29-eu)]

Good news! Using QEMU version 4.2.0 (Debian 1:4.2-3ubuntu1), I'm no longer able to reproduce this bug, key repeat is working properly.

[Christian Ehrhardt  (paelzer)]

Considering this done now without anything that we could backport to fix other releases.

Thanks:
@Leonardo for being an active reporter!
@Bryce for the workarounds from the X11 POV