Re: [PATCH v2 00/37] Add D-Bus display backend

[Gerd Hoffmann]

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>

> 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