Alyssa Ross <hi@alyssa.is> writes:
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 7/20/25 03:55, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
If I run `make run-qemu` under a Wayland compositor (tested with both Sway and Weston), I get a Wayland protocol error ("invalid object 0") and QEMU exits. It appears that there is a problem with wayland-proxy-virtwl. I get the following error from foot:
warn: main.c:437: 'C' is not a UTF-8 locale, falling back to 'C.UTF-8' warn: config.c:3520: no configuration found, using defaults Fontconfig warning: no <cachedir> elements found. Check configuration. Fontconfig warning: adding <cachedir>/var/cache/fontconfig</cachedir> Fontconfig warning: adding <cachedir prefix="xdg">fontconfig</cachedir> err: wayland.c:1714: no compositor err: wayland.c:2248: failed to flush wayland socket: Connection reset by peer
And the following from wayland-proxy-virtwl:
2025-07-20 02:14:48.638 wl-proxy [WARNING]: Error handling client: Invalid_argument("invalid bounds in Cstruct.LE.get_uint32 [0,0](4096) off=0 len=4")
This is partially fixed with <https://github.com/NixOS/nixpkgs/pull/419860>, which is more recent than Spectrum's pinned Nixpkgs. I expect to update that in the next few days, but until then, you can apply it on top of the Nixpkgs revision in lib/nixpkgs.default.nix, and then pass --arg config '{pkgsFun = import /path/to/nixpkgs;}' to any Spectrum Nix command.
With that change, I'm able to run foot fine in QEMU. gnome-text-editor runs but prints errors and looks weird, and Firefox doesn't even start. crosvm built from the same tag as rutabaga_gfx used by QEMU works fine, so I think it must be a QEMU bug. I spent some time yesterday trying to debug it, but didn't get anywhere so far. If I can't figure it out soon I'll open an upstream bug report.
That's a good idea. Would it be possible to use vhost-user as a workaround? That would use crosvm's implementation instead.
No. crosvm and QEMU have different ideas of what vhost-user-gpu. QEMU expects to provide all the graphical stuff itself, using the vhost-user-gpu protocol[1], whereas the crosvm one has the backend do almost everything (like every other vhost-user device — also much better for sandboxing).
[1]: https://www.qemu.org/docs/master/interop/vhost-user-gpu.html#vhost-user-gpu-...
Possibly the best way to test this would be to use crosvm, which also supports virtio-sound.