Bug 472622

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!

spice-vdagent added a workaround for this problem because GNOME had this exact problem (https://bugzilla.redhat.com/show_bug.cgi?id=1750120) --- in short, it sets the session type (not neccessarily XDG_SESSION_TYPE, which seems to be ignored by systemd) to "x11". However, with Plasma, the session type is still "tty" (for context, I'm starting plasma through bare startx, with no display manager).

On X11 kwin is not involved in clipboard sharing.