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 Desktop Packages, 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) Status in mutter package in Ubuntu: New Status in virt-manager package in Ubuntu: Invalid Bug description: I'm testing Ubuntu 20.04 LTS (Focal Fossa) Beta. I installed Kubuntu 20.04 and virt-manager as I did many times on Ubuntu 18.04. Unfortunatelly when I run a VM (QEMU-KVM, libvirt, libspice-server1 and spice-vdagent) with another Kubuntu 20.04 guest or with Ubuntu 20.04 guest then clipboard doesn't work right. To test it, please install Kubuntu 20.04 and then install Kubuntu / Ubuntu 20.04 as VM (guest). Open some simple text editor and start Ctrl + C and Ctrl + V plain text. 90% of time it will work and 10% of time it won't. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: virt-manager 1:2.2.1-3ubuntu1 ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27 Uname: Linux 5.4.0-21-generic x86_64 ApportVersion: 2.20.11-0ubuntu26 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: KDE Date: Mon Apr 13 15:02:22 2020 InstallationDate: Installed on 2020-04-09 (4 days ago) InstallationMedia: Kubuntu 20.04 LTS "Focal Fossa" - Beta amd64 (20200401) PackageArchitecture: all SourcePackage: virt-manager UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1872527/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
