Hi
On Wed, Oct 13, 2021 at 9:23 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
> On Sun, Oct 10, 2021 at 01:08:01AM +0400, marcandre.lureau@redhat.com
> wrote:
> > From: Marc-André Lureau <marcandre.lureau@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 <kraxel@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.lureau@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