Demi Marie Obenour <demiobenour@gmail.com> writes:

> On 7/20/25 04:20, Alyssa Ross wrote:
>> 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.
>
> I thought the only implemented backends were CrAS and Android.

Oh, maybe, but I think it also supports vhost-user-sound, so might be
usable with vhost-device?  I started packaging vhost-device-sound the
other day, btw.  Not quite done yet.