On 7/20/25 04:33, Alyssa Ross wrote:
> 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.

Oh nice.  Fedora wiki says that vhost-device-sound is in Fedora and
supports both ALSA and PipeWire.

I looked at CrAS and it requires udev, so I don't think there is
any reasonable way to avoid udev on the host.  However, eudev should
be sufficient, so systemd isn't needed.  I'm not sure if eudev needs
D-Bus, though an old blog post suggested it does not.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)