I finally got around to freeing up enough storage for an Ubuntu 26.04 VM. Then I remembered this thread, so I also installed lubuntu-desktop-minimal to see if I can reproduce this, and the answer is yes. There seem to be several issues with spice-vdagent{,d} in (L)Ubuntu, but I wanted to share the rather crude workaround I’ve found:
systemctl stop spice-vdagentd
That stops the system daemon, which should immediately restart, because it’s socket-activated and the user session agent (spice-vdagent) will thus bring it back. This seems to be necessary after every resize action of the guest window. Initially I thought it was a one-time thing, because I was able to resize to my heart’s content and the mouse stayed in sync, but somehow I cannot reliably reproduce that anymore.
I don’t know how useful this info is on this forum, because it should probably be part of a bug report, but here go my current findings:
- The user session agent,
spice-vdagent, is being started twice, once by some desktop session magic and, apparently after that, the other is a systemd user service, which fails exits because of the former, so systemctl --user restart spice-vdagent is useless without an override to ExecStartPre=-killall spice-vdagent
- There seems to be a race condition when the desktop session starts, because even with said override,
spice-vdagent.service fails to start:
Authorization required, but no authorization protocol specified
systemctl --user reload-or-restart spice-vdagent with overrides works, though, when the desktop is fully up and running, so I think there must be some ordering issue with another service.
This is the user service override:
$ systemctl --user edit spice-vdagent
[Service]
ExecStartPre=-killall spice-vdagent
I couldn’t be bothered (yet) to look into how the other instance gets started, but that one will otherwise make any restart action silently fail, because the agent seems to recognize the other instance and just quits with a success exit code (0).
With that override in place I can get the same result as with stopping (and socket-activated restarting) of the system daemon:
systemctl --user restart spice-vdagent
The issue seems to be caused by something reporting the wrong display resolution:
0x5a712a0430a0 received guest xorg resolution, arg1: 1920, arg2: 1080, size 20
That’s what I see (with debug logging) after switching from fullscreen, which is 1920x1080. Yet the guest seems to adjust the resolution alright but uses the false values for the mouse canvas, so now I’ve got a mouse that thinks it’s on a 1080p screen when it’s more like 720p.
Everything works fine with the default Ubuntu desktop session, BTW; SDDM vs. GDM3 also seems to make no difference.
This is interesting:
Jun 03 10:00:25 ubuntu-vm spice-vdagent[15888]: display: failed to call GetCurrentState from mutter over DBUS
Jun 03 10:00:25 ubuntu-vm spice-vdagent[15888]: 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
Jun 03 10:00:25 ubuntu-vm spice-vdagent[15888]: No guest output map, using output index as display id
Jun 03 10:00:25 ubuntu-vm spice-vdagent[15888]: Sending guest screen resolutions to vdagentd:
Jun 03 10:00:25 ubuntu-vm spice-vdagent[15888]: display_id=0 - 1920x1080+0+0
Jun 03 10:00:25 ubuntu-vm spice-vdagent[15888]: 0x5f3ab3296e80 sent guest xorg resolution, arg1: 1536, arg2: 865, size 20
Jun 03 10:00:25 ubuntu-vm spice-vdagentd[9257]: 0x5ce78a1e0720 received guest xorg resolution, arg1: 1536, arg2: 865, size 20
Jun 03 10:00:25 ubuntu-vm spice-vdagentd[9257]: 0x5ce78a1e0720 received guest xorg resolution, arg1: 1536, arg2: 865, size 20
Jun 03 10:00:25 ubuntu-vm spice-vdagentd[9257]: 0x5ce78a1e0720 received guest xorg resolution, arg1: 1536, arg2: 865, size 20
Jun 03 10:00:25 ubuntu-vm spice-vdagentd[9257]: 0x5ce78a1e0720 received guest xorg resolution, arg1: 1536, arg2: 865, size 20
Jun 03 10:00:25 ubuntu-vm spice-vdagentd[9257]: 0x5ce78a1e0720 received guest xorg resolution, arg1: 1536, arg2: 865, size 20
Jun 03 10:00:25 ubuntu-vm spice-vdagent[15888]: unhandled x11 event, type 33, window 31457298
Jun 03 10:00:25 ubuntu-vm spice-vdagent[15888]: unhandled x11 event, type 33, window 31457298
Jun 03 10:00:25 ubuntu-vm kscreen_backend_launcher[15861]: kscreen.xrandr: Emitting configChanged()
See how vdagent first says it’s sending 1920x1080 and then reports having sent 1536x865, the previous resolution, because that was after going fullscreen. It seems there is quite a tight coupling with GNOME, because in the default GNOME session, the DBUS errors are gone and in their place are logind messages about received signals.
It does seem to work with GDM3 as the display manager; that’s also why it initially worked and stopped after I switched to SDDM, which must be the default in Lubuntu.
Or maybe that’s just a sign of desperation due to some other prior failure in finding something to talk to about the display resolution. Is the host set to “Auto resize VM with window”? Also, changing the guest’s resolution by its own system tools may require to “Resize to VM” in