Hi Marc-André,
Ok, it is good to know dmabuf is used for sharing the scanout between
processes when using dbus or virt-viewer.
BTW,
I have some more comments on your previous answers. I just copied ans
pasted your previous comments. Sorry about any inconvenience caused by
this delayed response.
[Marc-André] The plan is there, GNOME has made bold moves in the past.
There is not much left in the TODO. But yes, it takes a bit longer than
expected.
[Dongwon] If Gnome abandons Xorg, then users would find other distros or
other desktop environments that support Xorg. My point is why should
Qemu GTK UI not support those distros/environments that support Xorg
today with new features? If maintainability is your concern, again we
can offer supporting this feature as long as there is a distro out there
that supports Xorg.
[Marc-André] Intuitive, perhaps. Discoverable and portable?
[Dongwon] We thought about doing the multi monitor mapping similar to
how virt-viewer is doing it but we chose monitor labels because they
uniquely identify the monitors even if they are repeatedly
unplugged/plugged which may not be possible if we use integer IDs to
represent monitors. For example, if virt-viewer client identifies a DP-1
with monitor ID 1 and a HDMI-1 with ID 2 and they are both unplugged and
HDMI-1 is hotplugged first, I don't think it would probably ID 1 with
HDMI-1 as there is no way for it to know without the label.
[Marc-André] Interesting case that could be added to virt-viewer if it's
necessary.
[Dongwon] The implementation might become very complex if we were to add
the "hotplug" functionality as opposed to the simplicity with which it
is done with Qemu GTK UI. And, it appears there is no flexibility to
make policy changes such as using monitor labels instead of monitor IDs.
And, btw, from a quick look, virt-viewer appears to use the same
API(gtk_window_move()) that we are relying on, so I guess a similar fate
awaits it if Xorg is gone or it switches to GTK4.
[Marc-André] Honestly, I don't support the idea of duplicating this
effort in QEMU.
[Dongwon] That is unfortunate. It is a similar, but a different feature
with "hotplug" and labels as its core as described earlier. I think it
may not be a great idea to force users who are already using Qemu GTK UI
given their use-cases, to use virt-viewer (which adds another layer of
complexity) just to use this feature.
[Dongwon]
Thanks!
On 6/14/2024 1:41 AM, Marc-André Lureau wrote:
Hi
On Thu, Jun 13, 2024 at 9:08 PM Kim, Dongwon <dongwon....@intel.com
<mailto:dongwon....@intel.com>> wrote:
> "hotplug" functionality where a Guest display/window is
deeply tied to a
> physical monitor to make it appear to the guest that it is
dealing with
> a real physical monitor.
>
> In other words, when the physical monitor is unplugged, the
associated
> guest display/window gets destroyed/hidden and gets
recreated/shown
> when
> the monitor is hotplugged again.
>
>
> Interesting case that could be added to virt-viewer if it's
necessary.
>
> The subject is sufficiently complex that there is already additional
> documentation/specification in:
>
https://gitlab.com/virt-viewer/virt-viewer/-/tree/master/docs?ref_type=heads
<https://gitlab.com/virt-viewer/virt-viewer/-/tree/master/docs?ref_type=heads>
<https://gitlab.com/virt-viewer/virt-viewer/-/tree/master/docs?ref_type=heads
<https://gitlab.com/virt-viewer/virt-viewer/-/tree/master/docs?ref_type=heads>>
>
> Honestly, I don't support the idea of duplicating this effort in
QEMU.
Marc-André,
My assumption is virt-viewer might not be able to completely replace
GTK-UI path in terms of performance and smoothness of display update as
(I think) frame copy between processes is implied, which is same as
There is no frame copy when using DMABUF scanouts between qemu and client.
Iow, the performance difference is negligible / noise level.
spice-remote viewer. What about display-bus that you have been working
on? Would it be a good alternative w.r.t perf concern that I specified
above?
There shouldn't be much difference for the local DMABUF display case.
>
> --
> Marc-André Lureau
--
Marc-André Lureau
