SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. Start QEMU and copy something in a Plasma guest. 2. Try to paste in the host OBSERVED RESULT Nothing gets pasted (or more likely, the last thing in the host's clipboard gets pasted). EXPECTED RESULT The thing copied in the guest gets pasted in the host SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION * This is similar to 462093, but this is about X11, not Wayland. * I remember reporting a similar bug before on an earlier version (455992), and one workaround was to use systemdboot. This workaround no longer works; however, I was able to get an error log by disabling systemdboot (no log is shown when systemdboot is enabled). The error reports something about a "UID Mismatch", similar to the error in the previous report.
Upon further reflection, the difference between 455992 and this bug is that this time, spice-vdagentd does start, it's just that now there's an error. As before, other DEs work as expected. The exact error: `UID mismatch: UID=1001 PID=653 suid=4294967295`
KWin is not involved with the clipboard on X11. If spice-vdagentd doesn't work, that's a bug that should be filed for spice-vdagentd.
But that doesn't make sense, as it works for every other DE I tried basically, every DE packaged for Arch).
I noticed that spice-vdagent (the one that runs as your user dies whenever you try to run it, with ``` spice-vdagent[428319]: vdagent started spice-vdagent[428319]: 0xaaaad276cbd0 connected to /run/spice-vdagentd/spice-vdagent-sock spice-vdagent[428319]: vdagent_display_create: net_wm_name="KWin", has icons=0 spice-vdagent[428319]: display: failed to call GetCurrentState from mutter over DBUS spice-vdagent[428319]: error message: Cannot invoke method; proxy is for the well-known name org.gnome.Mutter.DisplayConfig without an owner, and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag spice-vdagent[428319]: No guest output map, using output index as display id spice-vdagent[428319]: Sending guest screen resolutions to vdagentd: spice-vdagent[428319]: display_id=0 - 1280x800+0+0 spice-vdagent[428319]: 0xaaaad276cbd0 sent guest xorg resolution, arg1: 1280, arg2: 800, size 20 spice-vdagent[428319]: 0xaaaad276cbd0 disconnected ```
I fixed the problem by installing xdg-desktop-portal-gtk. I have no idea why this fixed the problem.
the portal probably implements some interface that spice-vdagentd prefers over whatever failed before. So please still report this upstream.
I'm still not sure it's a problem on SPICE's side --- if I downgrade to 5.24, it worked without installing anything.
I also seem to require vte-common.
Acutally, I noticed this doesn't actually solve the problem --- if I install them, and restart the VM, it work, but after 2 more restarts, the problem comes back again.
Again, this is a bug that you should report upstream
Oh, I learned something --- If you manually run xclip on the guest, the guest->host starts working. If you run pbpaste on the host, host->guest starts working. I'm not sure why it doesn't activate by itself though.
Update: I worked around this problem temporarily by switching to Xfce, which does not have this issue. However, I really like using KDE, and this issue has been in the back of my mind for a while, so I recently started into this again. After some debugging, this is due to a SIGSEGV crash in spice-vdagent at `vdagent_x11_do_read`/`XPending`. This is a known issue (just look up `spice- "vdagent" sigsegv`), but it only seems to effect KDE/KUbuntu.
I just found out that this is due to KDE not automatically setting XDG_SESSION_TYPE=x11 in systemd-logind upon executing startplasma-x11 (I'm using startx instead of a display manager).
Nope, that wasn't why (XFCE also doesn't set XDG_SESSION_TYPE). However, what is different between the two DEs is the cgroup hierarchy --- in XFCE, almost all user-level processes are uner the `session-1.slice` group (presumably owned by systemd). However, on KDE, each process is under a slice that is owned by the process that spawned them (for example, if I run `python` in the Kitty terminal, that `python` process would show up under the `app-kitty.slice`. Each of these app-level slices are under the general `session.slice`, so to systemd, almost none of the processes spawned are under any systemd cgroup/session!