From: "Kasireddy, Vivek" <vivek.kasireddy@intel.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Zhang, Tina" <tina.zhang@intel.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"Kim, Dongwon" <dongwon.kim@intel.com>
Subject: RE: [RFC v1 0/1] ui: Add a Wayland backend for Qemu UI
Date: Thu, 24 Jun 2021 18:17:12 +0000 [thread overview]
Message-ID: <9134eb849eb34f01a68802f8b754e61e@intel.com> (raw)
In-Reply-To: <20210624082812.kxgxdzayfnwr5q7q@sirius.home.kraxel.org>
Hi Gerd,
> > 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),
[Kasireddy, Vivek] Right, unfortunately, no decorations or other UI elements. For
that we can use GTK.
> right? Also the code seems to not (yet?) handle mouse and kbd input.
[Kasireddy, Vivek] Yes, kbd and mouse support not added yet and that is why I
tagged it as WIP. But it should not be too hard to add that.
>
> > 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 ...
[Kasireddy, Vivek] On our side, we'll also try to learn how dbus and pipewire
fit in and work. Having said that, can Marc-Andre's work be merged in
stages -- first only dbus and no pipewire?
Thanks,
Vivek
>
> take care,
> Gerd
prev parent reply other threads:[~2021-06-24 18:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-24 4:10 [RFC v1 0/1] ui: Add a Wayland backend for Qemu UI Vivek Kasireddy
2021-06-24 4:10 ` [RFC v1 1/1] ui: Add a plain " Vivek Kasireddy
2021-06-24 8:07 ` Philippe Mathieu-Daudé
2021-06-24 8:31 ` Thomas Huth
2021-06-24 4:30 ` [RFC v1 0/1] ui: Add a " no-reply
2021-06-24 8:28 ` Gerd Hoffmann
2021-06-24 18:17 ` Kasireddy, Vivek [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9134eb849eb34f01a68802f8b754e61e@intel.com \
--to=vivek.kasireddy@intel.com \
--cc=dongwon.kim@intel.com \
--cc=kraxel@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=tina.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.