Add D-Bus display backend 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 console API. Any -display or -audio backend should be possible to implement externally that way. D-Bus is the protocol of choice for the desktop, it has many convenient bindings for various languages, or tools (d-feet, busctl etc). Data blob transfer is more efficient than QMP too. This implementation makes use of p2p connections for data streaming, and a bus for basic introspection & interactions. It is currently Unix-only, but it should be possible to port to other systems relatively easily (minus fd-passing, which will have to use fallback or different methods). This will allow to lift some task from the QEMU process (Spice or VNC aren't trivial!). Backends can come and go. You can have several display opened (say Boxes & virt-manager), while exporting the display over VNC for example. An IPC interface is an easy starting point for writing backends in different languages. I started a Gtk4 & VNC backends in Rust. Rather than rewrite existing backends, it would be more interesting to develop new ones imho, such as a RDP backend (based on IronRDP & freerdp). An option is also to build the QEMU backends as D-Bus backends (maybe not too difficult). Given the current goals, the D-Bus interface is not meant to be stable. Clients/backends should be shipped together with QEMU. QEMU could ship its own Gtk4 widget/library (ideally written in Rust, with an exposed C/GIR API). The last part of the series modify vhost-user-gpu to notify directly the client of display changes, bypassing QEMU (VGA-time will be blank, atm) Basic testing: $ qemu-system- ... -display dbus And after git clone https://gitlab.com/marcandre.lureau/qemu-display.git $ cargo run --bin qemu-gtk4 Better to use with gl=on and virgl. You may also export audio with "-audiodev dbus" (see related patch).