Re: "make run-qemu" gets Wayland protocol error

[Alyssa Ross <hi@alyssa.is>]

[-- Attachment #1: Type: text/plain, Size: 2684 bytes --]

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

Possibly the best way to test this would be to use crosvm, which also
supports virtio-sound.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]