Hi Gerd,

> > I do understand that adding a new purely Wayland backend would make it
> > redundant given that GTK, SDL, Spice, etc already support Wayland;
> > however, I do not see any good options available for eliminating that blit.
> 
> Well, one idea is using dbus (discovery/setup) and pipewire (data
> streams) to allow other applications access the guest display (also audio, input, ...).
> Simliar to gnome exporting the wayland display that way for remote access and screen
> sharing.
> 
> pipewire supports using dmabufs, so that should allow to decouple user interface code
> from qemu without making compromises on performance, which is probably quite useful
> for a number of use cases, like a zero-copy wayland client, or a client using drm directly.
[Kasireddy, Vivek] We considered having a separate client but decided that adding the
relevant pieces to Qemu UI would be sufficient. We also felt that the interaction between
the client and Qemu for sharing the dmabuf (guest FB) would add to the overhead and
exacerbate synchronization issues. And, maintaining and distributing such a client would 
probably not be prudent for us right now.

> 
> Right now pipewire support is at "idea" level, there isn't even a proof-of-concept for that.
> So it surely doesn't help short-term, but IMHO this makes alot of sense medium/long-
> term.
[Kasireddy, Vivek] Ok, we'll explore this idea further to see if it would work for our use-case. 

> 
> Marc-André has experimental code for a dbus-based UI for qemu.  It doesn't use pipewire
> as data transport though.  At least the first version posted a while ago @ qemu-devel
> doesn't.
[Kasireddy, Vivek] What is the main motivation for a new dbus-based UI for Qemu?
Also, would you be able to review the patches in this series soon?

Thanks,
Vivek

> 
> take care,
>   Gerd

  Hi,

> > Marc-André has experimental code for a dbus-based UI for qemu.  It doesn't use pipewire
> > as data transport though.  At least the first version posted a while ago @ qemu-devel
> > doesn't.
> [Kasireddy, Vivek] What is the main motivation for a new dbus-based UI for Qemu?

Having UI and qemu run in separate processes has serveral advantages,
for starters the VM is independent from the desktop session.  Today you
can use vnc or spice, the dbus UI should allow better performance and
integration than that.  If it works out well we maybe we can even drop
the sdl/gtk UIs.

> Also, would you be able to review the patches in this series soon?

I expect there will be a v2 anyway due to the kernel-side changes?

take care,
  Gerd