Hi On Wed, Oct 13, 2021 at 9:23 AM Gerd Hoffmann <kra...@redhat.com> wrote:
> 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> > I have rebased the series and added your acked-by ( https://gitlab.com/marcandre.lureau/qemu/-/tree/dbus) The client side is still in development. However, the libvirt series is in shape ( https://patchew.org/Libvirt/20211202142411.1718032-1-marcandre.lur...@redhat.com/), waiting for QEMU side to land. Should I make a PR or ask for more reviews? Since this is fairly long to review but quite independent from existing code, I think sending a PR is reasonable wdyt? > > 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)? > > That's doable. I just added a --wait option to the demo client. For reconnect to work, we would need a better way to track name ownership changes (connection and disconnections) in zbus. I am working on it. thanks -- Marc-André Lureau
