On Sun, Oct 10, 2021 at 01:08:01AM +0400, marcandre.lur...@redhat.com wrote: > From: Marc-André Lureau <marcandre.lur...@redhat.com> > > Hi, > > Both Spice and VNC are relatively complex and inefficient for local-only > display/console export. > > The goal of this display backend is to export over D-Bus an interface close to > the QEMU internal APIs. Any -display or -audio backend should be possible to > implement externally that way. It will allow third-parties to maintain their > own > backends (UI toolkits, servers etc), and eventually reduce the responsability > on > QEMU. > > D-Bus is the protocol of choice for the desktop, it has many convenient > bindings > for various languages and tools. Data blob transfer is more efficient than QMP > too. Backends can come and go as needed: you can have several display opened > (say Boxes & virt-manager), while exporting the display over VNC for example > from a different process. It works best on Unix, but there is some Windows > support too (even Windows has some AF_UNIX nowadays, and the WSL2 situation > may > change the future of QEMU on Windows anyway). > > Using it only requires "-display dbus" on any reasonable Linux desktop with a > D-Bus session bus. Then you use can use busctl, d-feet or gdbus, ex: > $ gdbus introspect --session -r -d org.qemu -o / > > See the different patches and documentation for further options. The p2p=on > mode > should also allow users running bus-less (on MacOS for ex). We can also add > TCP > socket if needed (although more work would be needed in this case to replace > the FD-passing with some extra TCP listening socket).
Wow. That series got a lot of fine tuning. The patches look all good to me. Acked-by: Gerd Hoffmann <kra...@redhat.com> > A WIP Rust/Gtk4 client and VNC server is: > https://gitlab.com/marcandre.lureau/qemu-display/ > (check README.md for details, then `cargo run` should connect to QEMU) Hmm, that wants rather cutting edge versions, stock Fedora 34 isn't new enough to build it. And I don't feel like updating to Fedora 35 beta for that. So unfortunately I couldn't easily test it, but I'd love to see that live in action. Is it possible to keep the client running while starting and stopping qemu (comparable to "virt-viewer --wait --reconnect" behaviour)? take care, Gerd
