If you run a Fedora 35 KDE virt-manager (qemu/SPICE) VM on a Fedora 35 host, you cannot copy/paste to or from the guest. Doing this with a Fedora 35 Workstation guest works fine. Notes about the problem from IRC: apol: I looked into it some days ago Conan Kudo: oh? apol: vd_agent, doesn't pick it up apol: https://gitlab.freedesktop.org/spice/linux/vd_agent/-/commit/ca4dd7e8119e285ee9fee34ebaf151a759814b5d < this is the code in question apol: I didn't go as far as to try to fix it though, but if someone knows how I can easily look into it from my development system I might be able to look into it Conan Kudo: hmm, I guess we need to adjust spice-vdagent then apol: quite possibly apol: we have the necessary code in klipper and kde connect already, it's a matter of implementing it there I suppose Proposing this as an FE issue for F35 Final, as it's very annoying and I *think* the fix will be client side, so if we don't fix it before final, the bug will always exist when booting the KDE live image...
Adam, I tested here four setups on my F35Kde host and F35kde guest and found that: Host X11 / Guest Wayland => copy/paste doesn't work Host X11 / Guest X11 => copy/paste WORK Host Wayland / Guest Wayland => copy/paste doesn't work Host Wayland / Guest X11 => copy/paste WORK So, when guest is in xorg session copy paste allways work, and when guest is in wayland session, copy paste allways don't. Hope this help in something for the fix process.
Correct, on guest plasma wayland, we need to have ways for clients to talk to vdagent without giving vdagent focus. Much like we've had to do for the clipboard history applet and kde connect. FWIW, it should work now with Guest Wayland but copying from an XWayland application, since vdagent is in XWayland mode for some reason.
+3 in https://pagure.io/fedora-qa/blocker-review/issue/565 , marking accepted. Any chance anyone's figured out a fix for this?
This bug still persists, both on F35 with last updates and on F36 too, and behaves the same at F36: Host X11 / Guest Wayland => copy/paste doesn't work Host X11 / Guest X11 => copy/paste WORK Host Wayland / Guest Wayland => copy/paste doesn't work Host Wayland / Guest X11 => copy/paste WORK So @awilliam can we set this to F36 and call it for FE too?
Yeah, I'm still seeing it too :( Was hoping someone would've fixed it by now. Proposing for Beta FE.
+4 in https://pagure.io/fedora-qa/blocker-review/issue/666 , marking accepted.
Confirming that I still see this issue with Fedora 36 KDE Host: Fedora 35 Cinnamon with virt-manager.noarch 3.2.0-5.fc35 Guest: Fedora 36 KDE with spice-vdagent already installed. [test@fedora ~]$ inxi -S System: Host: fedora Kernel: 5.17.5-300.fc36.x86_64 arch: x86_64 bits: 64 Desktop: KDE Plasma v: 5.24.3 Distro: Fedora release 36 (Thirty Six) While guest is running Wayland session, copy/paste between guest and host does not work. Logging out and having guest use X11 session, it works fine again.
https://gitlab.freedesktop.org/spice/linux/vd_agent/-/blob/master/src/vdagent/clipboard.c < This seems to expect GTK to handle clipboards properly but it does not seem to. Wild guess would be they might have implemented a gnome-specific protocol in there? There is no clipboard monitoring standard, we Plasma are using wlr-data-control-unstable-v1.xml from wlroots and I can imagine that GTK didn't bother with it. I have not double-checked. I am not sure what's a good way forward as I am no GTK or vdagent developer. I guess a good first step would be to open a ticket upstream in vdagent.
Still valid on F37. Did anyone open an upstream ticket yet?
(In reply to Adam Williamson from comment #9) > Still valid on F37. Did anyone open an upstream ticket yet? maybe this one? https://gitlab.freedesktop.org/spice/linux/vd_agent/-/issues/26
Proposing as a Prioritized bug. It's very inconvenient that clipboard can't be shared with KDE virtual machines, both for end-users and developers/QA. It slows down any debugging and working with the system.
In today's prioritized bugs meeting, we agreed to reject this as a prioritized bug. The upstream project is not active, so prioritizing won't get us very far. Use of a remote desktop service in the VM is the suggested workaround https://meetbot.fedoraproject.org/fedora-meeting-1/2023-04-19/fedora_prioritized_bugs_and_issues.2023-04-19-14.00.log.html#l-73
...as if xdmcp etc is working..Which remote desktop solution is being proposed here??? It is sad that 18 years ago Linux had LTSP working flawlessly and today almost nothing works across network.
This message is a reminder that Fedora Linux 37 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '37'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 37 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
This is still a problem today.
Yes it is still a problem, I am having it on Fedora 39 with KDE.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 40 development cycle. Changing version to 40.
With KDE Plasma 6.0.3, you can now copy *to* VMs, but not *from* VMs, as the spice-vdagent's usage of the X11 clipboard for pushing things when not "in focus" now works. See: https://invent.kde.org/plasma/kwin/-/commit/760e35065ed8b5f570f757cc464473b5f75a3c5b
I am able to copy from the client vm and past in the host but **ONLY** if i copy from an intellijidea editor. All other applications fail. Fedora40 kde host, fedora40 kde vm.
You can use "xclip" for a workaround: On the guest: $ echo 'hello, world!' | xclip On the host: $ xclip hello, world! See, also, "xsel". $ rpm -q xclip xsel xclip-0.13-21.git11cba61.fc40.x86_64 xsel-1.2.1-1.fc40.x86_64
"gvim" can be used as an intermediate clipboard. On the guest, copy your text and paste it into a "gvim" window. On the host, the text can then be pasted where needed. $ rpm -qf /usr/bin/gvim vim-X11-9.1.660-1.fc40.x86_64
Yet another workaround is to use "xclipboard", which works fine with Wayland. "xclipboard" is a GUI app, and it supports a history. On the guest: Select some text in a terminal window. Click "New" in the "xclipboard" window. Center-click in the "xclipboard" text box. On the host: Center-click in the target window. $ rpm -q xclipboard xorg-x11-server-Xwayland plasma-workspace xclipboard-1.1.4-6.fc40.x86_64 xorg-x11-server-Xwayland-24.1.2-1.fc40.x86_64 plasma-workspace-6.1.4-1.fc40.x86_64
Doing shenanigans like xclipboard is worse than just using a text editor on both host and guest and open common text file to share the text but that is besides the point. The point here is to get the bug fixed and not ( keep it open for years and years and still pretend that we are using a modern OS).
(In reply to Parminder Lehal from comment #23) > ... using a text editor on both host and guest and open common text file to share the text ... I don't understand your workaround. Where does that "common text file" come from? Please post step-by-step instructions or commands.
Can this be prioritized somehow on the fact that it's still a problem after so many years and releases ? On the current FC40 spin you can paste into the VM but not out of it. Switching back to X11 wouldn't be so bad if every major release didn't try to force you to use Wayland over X11 again. And X11 comes with its own set of annoying issues with open-vm-tools because it doesn't handle the systemd scripts properly and every update to x11 turns that back on and breaks things. In regards to the 'workaround' mentioned with a text editor and the subsequent question, You open a file on a network share/shared folder in the VM and then the same file on the host and use that to copy and paste stuff with extra steps. Something like vscode will auto refresh its contents if you haven't modified it on both ends before saving 1.
(In reply to Conz from comment #25) ... > In regards to the 'workaround' mentioned with a text editor and the subsequent question, > You open a file on a network share/shared folder in the VM and > then the same file on the host and use that to copy and paste stuff with extra steps. > Something like vscode will auto refresh its contents if you haven't modified it on both ends before saving 1. Thanks for the clarification. Usually, I am pasting into a bug report, so there is no shared folder. Using xclipboard seems to be the best workaround for that use case.
This message is a reminder that Fedora Linux 40 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 40 on 2025-05-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '40'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 40 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Totally shameful behavior by RedHat. As if the bug has been fixed in Fedora 42 or RawHide.Why don't you just get rid of this sham of bug reporting?
This is still a problem in 41. i haven't upgraded to 42 yet but I'm assuming the same problem.
Yeah. Plasma has implemented the new ext-data-control Wayland protocol for Plasma 6.4, so now spice-vdagent needs to implement the client side of that.