You are not logged in.
Hi all,
After doing a full system upgrade (environment is xfce, virt-manager), clipboard synchronization between my host and Windows guests (Win7, Win10, Win11) has started behaving unexpectedly. My last known working state was from a full system upgrade on 2024-12-23.
Issue:
- Copying in Excel causes the copied selection indicator to immediately disappear.
- The clipboard retains a plaintext version of the copied content, but formatted pasting within Excel fails.
- If I copy the same data twice, the issue does not occur, suggesting clipboard synchronization may be skipping duplicate contents for efficiency and therefore not tampering with the clipboard.
A brief rundown of my observations and troubleshooting:
- Environment: All guests are running qemu-ga, virtio drivers, and spice-vdagent, which have worked without issue for years.
- Reinstalled latest versions of virtio, qemu-ga, spice-tools in the Win10 VM as a test, the issue still persists.
- Severing the Spice socket or stopping vdagent resolves the issue, but obviously disables clipboard sync.
- The issue appears host-side, as leaving vdagent running but disconnecting the socket stops the clipboard from being tampered with.
- No relevant logs found in /var/log/libvirt/. They're speaky-clean, no errors, just logs for successful start and stop.
I looked through bug trackers in QEMU, vdagent/spice, guest agent, and virt-manager, and it appears I am alone on this issue.
This suggests a recent change in clipboard handling within QEMU/Spice. Has anyone else encountered this, or does anyone have suggestions for further debugging?
I've been attempting to correct this for two days, and am at the point of running out of ideas.
Thanks in advance!
Last edited by Arthur (2025-03-30 09:55:19)
Offline
Which version of libxfce4ui are you using? There was a recent fix in 4.20.1 that may help: https://gitlab.xfce.org/xfce/libxfce4ui/-/issues/125
Offline
Hello, thank you for your reply,
Currently I am using 4.20.1-1 , I am up to date on packages as of yesterday unfortunately.
I'm also not using clipman, much like that bug poster
I wish there was a way of logging/debugging what is accessing the clipboard, etc, it would be interesting to see.
Offline
I'm also not using clipman, much like that bug poster
As said in this issue, you should also run xfsettingsd with XFSETTINGSD_NO_CLIPBOARD=1 to be sure that xfce's clipboard manager doesn't interfere.
aka Tamaranch: https://gitlab.xfce.org/Tamaranch
Offline
After running
XFSETTINGSD_NO_CLIPBOARD=1 xfsettingsd --replace
in my current session, I can confirm the clipboard idiocy stops.
After a very small amount of research *why* this happened, I see it was due to a unification of clipboard manager code in libxfce4ui, slated for 4.20 causing the unintended behavior.
One last question for (also for anyone else who might come across this thread), what would be the most optimal way of making XFSETTINGSD_NO_CLIPBOARD=1 permanent?
Offline
It seems to be specific to the use of qemu, or at least virtual machines, I'll have to try to reproduce the problem, I don't have time right now.
One last question for (also for anyone else who might come across this thread), what would be the most optimal way of making XFSETTINGSD_NO_CLIPBOARD=1 permanent?
As with any environment variable, you could for example put it in ~/.profile, which should be sourced at session startup, or in /etc/environment.
aka Tamaranch: https://gitlab.xfce.org/Tamaranch
Offline
So, an interesting update,
My VM clipboards have been working flawlessly since, however I went to take a screenshot (screenshooter) and I've lost my ability to send the screenshot to the clipboard.
Upon doing so, I decided to open clipman, to see if that would allow it to work. It did successfully bring back the option to put the screenshot on my clipboard.
While clipman is open and managing the clipboard, my VMs now exhibit that same erratic clipboard behaviour as in my original post. I found that to be quite interesting.
Offline
Not so much, no:
My VM clipboards have been working flawlessly since, however I went to take a screenshot (screenshooter) and I've lost my ability to send the screenshot to the clipboard.
This is a case where a "clipboard manager", in the sense of a place where applications can store their data before quitting, is needed: xfce4-screenshoter takes its screenshot and quits, so it needs to have somewhere to put that image so you can retrieve it.
Upon doing so, I decided to open clipman, to see if that would allow it to work. It did successfully bring back the option to put the screenshot on my clipboard.
While clipman is open and managing the clipboard, my VMs now exhibit that same erratic clipboard behaviour as in my original post.
This is normal: the clipboard manager in the low-level (or daemon) sense above can be provided either by xfsettingsd or by xfce4-clipman-plugin: the first one started takes on this role. xfce4-clipman-plugin also adds clipboard manager functionalities in the perhaps more common sense of the term (high-level, i.e. UI with menu, etc.).
Since the low-level clipboard manager code has been shared in libxfce4ui, as you pointed out in a previous comment, xfsettingsd and xfce4-clipman-plugin behave exactly the same in this respect, since they now run the same code. So nothing interesting or surprising here.
What might be useful, however, is if you could test the current state of the master or xfce-4.20 branches of libxfce4ui, which contain memory management patches that could have an impact on your problem, although apparently not enough to fix it.
aka Tamaranch: https://gitlab.xfce.org/Tamaranch
Offline