Re: [RFC v1 0/1] ui: Add a Wayland backend for Qemu UI

[Gerd Hoffmann]

On Wed, Jun 23, 2021 at 09:10:39PM -0700, Vivek Kasireddy wrote:
> Why does Qemu need a new Wayland UI backend?
> The main reason why there needs to be a plain and simple Wayland backend
> for Qemu UI is to eliminate the Blit (aka GPU copy) that happens if using
> a toolkit like GTK or SDL (because they use EGL). The Blit can be eliminated
> by sharing the dmabuf fd -- associated with the Guest scanout buffer --
> directly with the Host compositor via the linux-dmabuf (unstable) protocol.

Hmm, that probably means no window decorations (and other UI elements),
right?  Also the code seems to not (yet?) handle mouse and kbd input.

> The patch(es) are still WIP and the only reason why I am sending them now
> is to get feedback and see if anyone thinks this work is interesting. And,
> even after this work is complete, it is not meant to be merged and can be
> used for performance testing purposes. Given Qemu UI's new direction, the
> proper way to add new backends is to create a separate UI/display module
> that is part of the dbus/pipewire infrastructure that Marc-Andre is
> working on:
> https://lists.nongnu.org/archive/html/qemu-devel/2021-03/msg04331.html

Separating emulation and UI has the big advantage that the guest
lifecycle is decoupled from the desktop session lifecycle, i.e.
the guest can continue to run when the desktop session ends.

Works today with spice (when using unix socket to connect it can pass
dma-buf handles from qemu to spice client).

Using dbus instead certainly makes sense.  Whenever we'll just go send
dma-buf handles over dbus or integrate with pipewire for display/sound
not clear yet.  Marc-André thinks using pipewire doesn't bring benefits
and I havn't found the time yet to learn more about pipewire ...

take care,
  Gerd