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-protocol