Re: [RFC PATCH v2 0/2] ui/gtk: Introduce new param - Connectors

["Kim, Dongwon" <dongwon.kim@intel.com>]

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.kim@intel.com 
> <mailto:dongwon.kim@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