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
