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>
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