Arch Linux

Arthur

Member

Registered: 2025-03-27

Posts: 3

[SOLVED] Investigating Clipboard Sync Issues in QEMU/Spice

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)

correctmost

Member

Registered: 2024-01-20

Posts: 8

Re: [SOLVED] Investigating Clipboard Sync Issues in QEMU/Spice

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

Arthur

Member

Registered: 2025-03-27

Posts: 3

Re: [SOLVED] Investigating Clipboard Sync Issues in QEMU/Spice

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.

lambdarch

Member

From: France

Registered: 2021-01-10

Posts: 92

Website

Re: [SOLVED] Investigating Clipboard Sync Issues in QEMU/Spice

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

Arthur

Member

Registered: 2025-03-27

Posts: 3

Re: [SOLVED] Investigating Clipboard Sync Issues in QEMU/Spice

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?

lambdarch

Member

From: France

Registered: 2021-01-10

Posts: 92

Website

Re: [SOLVED] Investigating Clipboard Sync Issues in QEMU/Spice

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