It sort of sounds like there is a race condition going on in the consumption of the key sequence. I don't want to guess exactly what the problem is in this particular case, but just as general X info (which you probably already know...):
Keyboard input is processed through several levels... hardware, kernel, X server, input manager, window manager, and applications. And virtualization adds another layer in there too. Each layer does some translation, such as from hardware key events into key id's, id's translated into language-specific key symbols, key symbols like [ctrl, v] into key combos/sequences like ^v, sequences into commands like "paste", etc. At any of these layers, an input event can be "consumed", making it not available to other things later in the layers. Comment #2 in particular seems to do a good job of narrowing where the issue occurs. Using screenkey to verify the key events are reaching the guest rules out hardware layer through virtualization. Reproducing the bug in GNOME as well as KDE seems to rule out window manager. So... my guess would be to look at what applications (or services) might also be trying to consume the key sequence. GNOME (and KDE) coordinate the key handling by applications, so that would be a first thing to check. Is it also possible there is a non-GTK /non-Qt service, process, or app that is skipping that (X can be a bit overly permissive...) A couple tools that can be useful for probing/debugging keyboard handling issues are `xev` and `xdotool`. The former shows you debug information as you hit keys, the latter lets you synthetically create them. For example: xdotool mousedown --clearmodifiers 2 xdotool mouseup 2 xdotool keyup alt xdotool keyup ctrl xdotool keyup shift xev should be pretty self explanatory. On a different note... You probably already know about Linux's primary and secondary clipboards. Sometimes confusion derives from things getting copied to the other clipboard than intended, which can be tested. Other times it seems some app gets a lock on one clipboard or puts it into some sort of mode so nothing can copy into it; you may run into this with firefox or other non-GNOME/non-KDE apps used in a GNOME or KDE environment. So, see if you can rule out whether the problem can be localized to the handling of the key events, or if it is specific to the copying, or the pasting behavior. And examine what processes are running, and in particular note any non-KDE/non-GNOME things that may be inserting themselves. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to mutter in Ubuntu. https://bugs.launchpad.net/bugs/1872527 Title: Clipboard doesn't work 100% of the time in Ubuntu 20.04 (in KVM guests) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1872527/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
