mbox series

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

Message ID 20240531185804.119557-1-dongwon.kim@intel.com (mailing list archive)
Headers show
Series ui/gtk: Introduce new param - Connectors | expand

Message

Kim, Dongwon May 31, 2024, 6:58 p.m. UTC
From: Dongwon Kim <dongwon.kim@intel.com>

This patch series is a replacement of
https://mail.gnu.org/archive/html/qemu-devel/2023-06/msg03989.html

There is a need, expressed by several users, to assign ownership of one
or more physical monitors/connectors to individual guests. This creates
a clear notion of which guest's contents are being displayed on any given
monitor. Given that there is always a display server/compositor running
on the host, monitor ownership can never truly be transferred to guests.
However, the closest approximation is to request the host compositor to
fullscreen the guest's windows on individual monitors. This allows for
various configurations, such as displaying four different guests' windows
on four different monitors, a single guest's windows (or virtual consoles)
on four monitors, or any similar combination.

This patch series attempts to accomplish this by introducing a new
parameter named "connector" to assign monitors to the GFX VCs associated
with a guest. If the assigned monitor is not connected, the guest's window
will not be displayed, similar to how a host compositor behaves when
connectors are not connected. Once the monitor is hot-plugged, the guest's
window(s) will be positioned on the assigned monitor.

Usage example:

-display gtk,gl=on,connectors=DP-1:eDP-1:HDMI-2...

In this example, the first graphics virtual console will be placed on the
DP-1 display, the second on eDP-1, and the third on HDMI-2.

v2: Connectors is now in a string format that includes all connector names
    separated with a colon (previously it was a linked list)

    Code refactoring

Vivek Kasireddy (2):
  ui/gtk: Factor out tab window creation into a separate
  ui/gtk: Add a new parameter to assign connectors/monitors

 qapi/ui.json     |  25 +++-
 include/ui/gtk.h |   1 +
 ui/gtk.c         | 301 +++++++++++++++++++++++++++++++++++++++++++----
 qemu-options.hx  |   4 +
 4 files changed, 308 insertions(+), 23 deletions(-)

Comments

Marc-André Lureau June 4, 2024, 10:37 a.m. UTC | #1
Hi

On Fri, May 31, 2024 at 11:00 PM <dongwon.kim@intel.com> wrote:

> From: Dongwon Kim <dongwon.kim@intel.com>
>
> This patch series is a replacement of
> https://mail.gnu.org/archive/html/qemu-devel/2023-06/msg03989.html
>
> There is a need, expressed by several users, to assign ownership of one
> or more physical monitors/connectors to individual guests. This creates
> a clear notion of which guest's contents are being displayed on any given
> monitor. Given that there is always a display server/compositor running
> on the host, monitor ownership can never truly be transferred to guests.
> However, the closest approximation is to request the host compositor to
> fullscreen the guest's windows on individual monitors. This allows for
> various configurations, such as displaying four different guests' windows
> on four different monitors, a single guest's windows (or virtual consoles)
> on four monitors, or any similar combination.
>
> This patch series attempts to accomplish this by introducing a new
> parameter named "connector" to assign monitors to the GFX VCs associated
> with a guest. If the assigned monitor is not connected, the guest's window
> will not be displayed, similar to how a host compositor behaves when
> connectors are not connected. Once the monitor is hot-plugged, the guest's
> window(s) will be positioned on the assigned monitor.
>
> Usage example:
>
> -display gtk,gl=on,connectors=DP-1:eDP-1:HDMI-2...
>
> In this example, the first graphics virtual console will be placed on the
> DP-1 display, the second on eDP-1, and the third on HDMI-2.
>
>
Unfortunately, this approach with GTK is doomed. gtk4 dropped the
gtk_window_set_position() altogether.

It's not even clear how the different monitors/outputs/connectors are
actually named, whether they are stable etc (not mentioning the
portability).

Window placement & geometry is a job for the compositor. Can you discuss
this issue with GTK devs & the compositor you are targeting?
Kim, Dongwon June 4, 2024, 5:59 p.m. UTC | #2
Hi Marc-André,

On 6/4/2024 3:37 AM, Marc-André Lureau wrote:
> Hi
> 
> On Fri, May 31, 2024 at 11:00 PM <dongwon.kim@intel.com 
> <mailto:dongwon.kim@intel.com>> wrote:
> 
>     From: Dongwon Kim <dongwon.kim@intel.com <mailto:dongwon.kim@intel.com>>
> 
>     This patch series is a replacement of
>     https://mail.gnu.org/archive/html/qemu-devel/2023-06/msg03989.html
>     <https://mail.gnu.org/archive/html/qemu-devel/2023-06/msg03989.html>
> 
>     There is a need, expressed by several users, to assign ownership of one
>     or more physical monitors/connectors to individual guests. This creates
>     a clear notion of which guest's contents are being displayed on any
>     given
>     monitor. Given that there is always a display server/compositor running
>     on the host, monitor ownership can never truly be transferred to guests.
>     However, the closest approximation is to request the host compositor to
>     fullscreen the guest's windows on individual monitors. This allows for
>     various configurations, such as displaying four different guests'
>     windows
>     on four different monitors, a single guest's windows (or virtual
>     consoles)
>     on four monitors, or any similar combination.
> 
>     This patch series attempts to accomplish this by introducing a new
>     parameter named "connector" to assign monitors to the GFX VCs associated
>     with a guest. If the assigned monitor is not connected, the guest's
>     window
>     will not be displayed, similar to how a host compositor behaves when
>     connectors are not connected. Once the monitor is hot-plugged, the
>     guest's
>     window(s) will be positioned on the assigned monitor.
> 
>     Usage example:
> 
>     -display gtk,gl=on,connectors=DP-1:eDP-1:HDMI-2...
> 
>     In this example, the first graphics virtual console will be placed
>     on the
>     DP-1 display, the second on eDP-1, and the third on HDMI-2.
> 
> 
> Unfortunately, this approach with GTK is doomed. gtk4 dropped the 
> gtk_window_set_position() altogether.

Do you mean we have a plan to lift GTK version in QEMU? Are we going to 
lose all GTK3 specific features?

> 
> It's not even clear how the different monitors/outputs/connectors are 
> actually named, whether they are stable etc (not mentioning the 
> portability).
> 
> Window placement & geometry is a job for the compositor. Can you discuss 
> this issue with GTK devs & the compositor you are targeting?

I guess you are talking about wayland compositor. We are mainly using 
Xorg on the host and this feature works pretty good on it. I am 
wondering if we limit the feature to Xorg case or adding some warning 
messages with error return in case any of parts is not working?
(like the warning message I added

+        model = gdk_monitor_get_model(monitor);
+        if (!model) {
+            g_warning("retrieving connector name using\n"
+                      "gdk_monitor_get_model isn't supported\n"
+                      "please do not use connectors param in\n"
+                      "current environment\n");
+            return -1;
+        }
)

> 
> -- 
> Marc-André Lureau
Marc-André Lureau June 5, 2024, 7:26 a.m. UTC | #3
Hi

On Tue, Jun 4, 2024 at 9:59 PM Kim, Dongwon <dongwon.kim@intel.com> wrote:

> Hi Marc-André,
>
> On 6/4/2024 3:37 AM, Marc-André Lureau wrote:
> > Hi
> >
> > On Fri, May 31, 2024 at 11:00 PM <dongwon.kim@intel.com
> > <mailto:dongwon.kim@intel.com>> wrote:
> >
> >     From: Dongwon Kim <dongwon.kim@intel.com <mailto:
> dongwon.kim@intel.com>>
> >
> >     This patch series is a replacement of
> >     https://mail.gnu.org/archive/html/qemu-devel/2023-06/msg03989.html
> >     <https://mail.gnu.org/archive/html/qemu-devel/2023-06/msg03989.html>
> >
> >     There is a need, expressed by several users, to assign ownership of
> one
> >     or more physical monitors/connectors to individual guests. This
> creates
> >     a clear notion of which guest's contents are being displayed on any
> >     given
> >     monitor. Given that there is always a display server/compositor
> running
> >     on the host, monitor ownership can never truly be transferred to
> guests.
> >     However, the closest approximation is to request the host compositor
> to
> >     fullscreen the guest's windows on individual monitors. This allows
> for
> >     various configurations, such as displaying four different guests'
> >     windows
> >     on four different monitors, a single guest's windows (or virtual
> >     consoles)
> >     on four monitors, or any similar combination.
> >
> >     This patch series attempts to accomplish this by introducing a new
> >     parameter named "connector" to assign monitors to the GFX VCs
> associated
> >     with a guest. If the assigned monitor is not connected, the guest's
> >     window
> >     will not be displayed, similar to how a host compositor behaves when
> >     connectors are not connected. Once the monitor is hot-plugged, the
> >     guest's
> >     window(s) will be positioned on the assigned monitor.
> >
> >     Usage example:
> >
> >     -display gtk,gl=on,connectors=DP-1:eDP-1:HDMI-2...
> >
> >     In this example, the first graphics virtual console will be placed
> >     on the
> >     DP-1 display, the second on eDP-1, and the third on HDMI-2.
> >
> >
> > Unfortunately, this approach with GTK is doomed. gtk4 dropped the
> > gtk_window_set_position() altogether.
>
> Do you mean we have a plan to lift GTK version in QEMU? Are we going to
> lose all GTK3 specific features?
>

No concrete plan, no. But eventually GTK3 will go away some day.

fwiw, I wish QEMU wouldn't have N built-in UIs/Spice/VNC, but different
projects elsewhere using -display dbus. There is
https://gitlab.gnome.org/GNOME/libmks or
https://gitlab.com/marcandre.lureau/qemu-display gtk4 efforts.


> >
> > It's not even clear how the different monitors/outputs/connectors are
> > actually named, whether they are stable etc (not mentioning the
> > portability).
> >
> > Window placement & geometry is a job for the compositor. Can you discuss
> > this issue with GTK devs & the compositor you are targeting?
>
> I guess you are talking about wayland compositor. We are mainly using
> Xorg on the host and this feature works pretty good on it. I am
>

Xorg may not be going away soon, but it's used less and less. As one of the
developers, I am no longer running/testing it for a long time. I wish we
would just drop its support tbh.

wondering if we limit the feature to Xorg case or adding some warning
> messages with error return in case any of parts is not working?
> (like the warning message I added
>
> +        model = gdk_monitor_get_model(monitor);
> +        if (!model) {
> +            g_warning("retrieving connector name using\n"
> +                      "gdk_monitor_get_model isn't supported\n"
> +                      "please do not use connectors param in\n"
> +                      "current environment\n");
> +            return -1;
> +        }
> )
>

Is it really worth maintaining this upstream if we know it will only work
for a diminishing fraction of users?
Kim, Dongwon June 11, 2024, 6:28 p.m. UTC | #4
Hi Marc-André,

On 6/5/2024 12:26 AM, Marc-André Lureau wrote:
> Hi
> 
> On Tue, Jun 4, 2024 at 9:59 PM Kim, Dongwon <dongwon.kim@intel.com 
> <mailto:dongwon.kim@intel.com>> wrote:
> 
>     Hi Marc-André,
> 
>     On 6/4/2024 3:37 AM, Marc-André Lureau wrote:
>      > Hi
>      >
>      > On Fri, May 31, 2024 at 11:00 PM <dongwon.kim@intel.com
>     <mailto:dongwon.kim@intel.com>
>      > <mailto:dongwon.kim@intel.com <mailto:dongwon.kim@intel.com>>> wrote:
>      >
>      >     From: Dongwon Kim <dongwon.kim@intel.com
>     <mailto:dongwon.kim@intel.com> <mailto:dongwon.kim@intel.com
>     <mailto:dongwon.kim@intel.com>>>
>      >
>      >     This patch series is a replacement of
>      >
>     https://mail.gnu.org/archive/html/qemu-devel/2023-06/msg03989.html
>     <https://mail.gnu.org/archive/html/qemu-devel/2023-06/msg03989.html>
>      >   
>       <https://mail.gnu.org/archive/html/qemu-devel/2023-06/msg03989.html <https://mail.gnu.org/archive/html/qemu-devel/2023-06/msg03989.html>>
>      >
>      >     There is a need, expressed by several users, to assign
>     ownership of one
>      >     or more physical monitors/connectors to individual guests.
>     This creates
>      >     a clear notion of which guest's contents are being displayed
>     on any
>      >     given
>      >     monitor. Given that there is always a display
>     server/compositor running
>      >     on the host, monitor ownership can never truly be transferred
>     to guests.
>      >     However, the closest approximation is to request the host
>     compositor to
>      >     fullscreen the guest's windows on individual monitors. This
>     allows for
>      >     various configurations, such as displaying four different guests'
>      >     windows
>      >     on four different monitors, a single guest's windows (or virtual
>      >     consoles)
>      >     on four monitors, or any similar combination.
>      >
>      >     This patch series attempts to accomplish this by introducing
>     a new
>      >     parameter named "connector" to assign monitors to the GFX VCs
>     associated
>      >     with a guest. If the assigned monitor is not connected, the
>     guest's
>      >     window
>      >     will not be displayed, similar to how a host compositor
>     behaves when
>      >     connectors are not connected. Once the monitor is
>     hot-plugged, the
>      >     guest's
>      >     window(s) will be positioned on the assigned monitor.
>      >
>      >     Usage example:
>      >
>      >     -display gtk,gl=on,connectors=DP-1:eDP-1:HDMI-2...
>      >
>      >     In this example, the first graphics virtual console will be
>     placed
>      >     on the
>      >     DP-1 display, the second on eDP-1, and the third on HDMI-2.
>      >
>      >
>      > Unfortunately, this approach with GTK is doomed. gtk4 dropped the
>      > gtk_window_set_position() altogether.
> 
>     Do you mean we have a plan to lift GTK version in QEMU? Are we going to
>     lose all GTK3 specific features?
> 
> 
> No concrete plan, no. But eventually GTK3 will go away some day.

There are users who still rely on features provided by GTK3 and we also 
have customers who are moving from VMware, virtualbox that have 
requested for this feature. Their use-cases are current and active. If 
windows repositioning won't be supported someday, then we would need to 
make this feature obsolete but many users/customers would benefit from 
it until then.

> 
> fwiw, I wish QEMU wouldn't have N built-in UIs/Spice/VNC, but different 
> projects elsewhere using -display dbus. There is 
> https://gitlab.gnome.org/GNOME/libmks 
> <https://gitlab.gnome.org/GNOME/libmks> or 
> https://gitlab.com/marcandre.lureau/qemu-display 
> <https://gitlab.com/marcandre.lureau/qemu-display> gtk4 efforts.

As you know, there cannot be a one size fits all solution that would 
work for all the users, which is probably why there are many Qemu UIs.

> 
> 
>      >
>      > It's not even clear how the different monitors/outputs/connectors
>     are
>      > actually named, whether they are stable etc (not mentioning the
>      > portability).
>      >
>      > Window placement & geometry is a job for the compositor. Can you
>     discuss
>      > this issue with GTK devs & the compositor you are targeting?
> 
>     I guess you are talking about wayland compositor. We are mainly using
>     Xorg on the host and this feature works pretty good on it. I am
> 
> 
> Xorg may not be going away soon, but it's used less and less. As one of 
> the developers, I am no longer running/testing it for a long time. I 
> wish we would just drop its support tbh.

There are features offered by Xorg that are not offered by Wayland 
compositors and again, we have customers that rely on these features.
One of them is the ability to position the window via 
gtk_window_set_position(). There are strong arguments
made on either side when it comes to window positioning:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247

Until there is a way to do this with Wayland compositors, we have to 
unfortunately rely on Gnome + Xorg.

> 
>     wondering if we limit the feature to Xorg case or adding some warning
>     messages with error return in case any of parts is not working?
>     (like the warning message I added
> 
>     +        model = gdk_monitor_get_model(monitor);
>     +        if (!model) {
>     +            g_warning("retrieving connector name using\n"
>     +                      "gdk_monitor_get_model isn't supported\n"
>     +                      "please do not use connectors param in\n"
>     +                      "current environment\n");
>     +            return -1;
>     +        }
>     )
> 
> 
> Is it really worth maintaining this upstream if we know it will only 
> work for a diminishing fraction of users?

As mentioned above, we are going to have maintain it for the 
customers/users who have use-cases that rely on this.

> 
> 
> 
> -- 
> Marc-André Lureau
Marc-André Lureau June 12, 2024, 6:42 a.m. UTC | #5
Hi

On Tue, Jun 11, 2024 at 10:28 PM Kim, Dongwon <dongwon.kim@intel.com> wrote:

> Hi Marc-André,
>
> On 6/5/2024 12:26 AM, Marc-André Lureau wrote:
> > Hi
> >
> > On Tue, Jun 4, 2024 at 9:59 PM Kim, Dongwon <dongwon.kim@intel.com
> > <mailto:dongwon.kim@intel.com>> wrote:
>
> Xorg may not be going away soon, but it's used less and less. As one of
> > the developers, I am no longer running/testing it for a long time. I
> > wish we would just drop its support tbh.
>
> There are features offered by Xorg that are not offered by Wayland
> compositors and again, we have customers that rely on these features.
> One of them is the ability to position the window via
> gtk_window_set_position(). There are strong arguments
> made on either side when it comes to window positioning:
>
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247
>
> Until there is a way to do this with Wayland compositors, we have to
> unfortunately rely on Gnome + Xorg.
>
>
It's a smaller and smaller number of users. The potential/future users are
greater if we focus on Wayland.

Fwiw, GNOME (and RHEL) is set to drop Xorg support (
https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/98)

Btw, there is a similar monitor-mapping functionality implemented in
virt-viewer/remote-viewer:
https://www.mankier.com/1/virt-viewer#Configuration. Is this something that
those users could use instead?
Kim, Dongwon June 12, 2024, 11:33 p.m. UTC | #6
On 6/11/2024 11:42 PM, Marc-André Lureau wrote:
> Hi
> 
> On Tue, Jun 11, 2024 at 10:28 PM Kim, Dongwon <dongwon.kim@intel.com 
> <mailto:dongwon.kim@intel.com>> wrote:
> 
>     Hi Marc-André,
> 
>     On 6/5/2024 12:26 AM, Marc-André Lureau wrote:
>      > Hi
>      >
>      > On Tue, Jun 4, 2024 at 9:59 PM Kim, Dongwon
>     <dongwon.kim@intel.com <mailto:dongwon.kim@intel.com>
>      > <mailto:dongwon.kim@intel.com <mailto:dongwon.kim@intel.com>>> wrote:
> 
>      > Xorg may not be going away soon, but it's used less and less. As
>     one of
>      > the developers, I am no longer running/testing it for a long time. I
>      > wish we would just drop its support tbh.
> 
>     There are features offered by Xorg that are not offered by Wayland
>     compositors and again, we have customers that rely on these features.
>     One of them is the ability to position the window via
>     gtk_window_set_position(). There are strong arguments
>     made on either side when it comes to window positioning:
>     https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247 <https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247>
> 
>     Until there is a way to do this with Wayland compositors, we have to
>     unfortunately rely on Gnome + Xorg.
> 
> 
> It's a smaller and smaller number of users. The potential/future users 
> are greater if we focus on Wayland.

Right, but until Gtk + Wayland offers the same feature parity and 
customization as that of Gtk + Xorg, there will be distros/users that 
will keep it alive.
> 
> Fwiw, GNOME (and RHEL) is set to drop Xorg support 
> (https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/98 
> <https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/98>)

Doesn't look like it is going to happen anytime soon given the massive 
pushback.

> 
> Btw, there is a similar monitor-mapping functionality implemented in 
> virt-viewer/remote-viewer: 
> https://www.mankier.com/1/virt-viewer#Configuration 
> <https://www.mankier.com/1/virt-viewer#Configuration>. Is this something 
> that those users could use instead?

It looks a bit similar and interesting but one difference is that our 
feature uses monitor labels such as DP-1, HDMI-2 which is a bit more 
intuitive. And, the other key difference is that our feature includes 
"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.

> 
> 
> -- 
> Marc-André Lureau
Marc-André Lureau June 13, 2024, 6:56 a.m. UTC | #7
Hi

On Thu, Jun 13, 2024 at 3:34 AM Kim, Dongwon <dongwon.kim@intel.com> wrote:

> On 6/11/2024 11:42 PM, Marc-André Lureau wrote:
> > Hi
> >
> > On Tue, Jun 11, 2024 at 10:28 PM Kim, Dongwon <dongwon.kim@intel.com
> > <mailto:dongwon.kim@intel.com>> wrote:
> >
> >     Hi Marc-André,
> >
> >     On 6/5/2024 12:26 AM, Marc-André Lureau wrote:
> >      > Hi
> >      >
> >      > On Tue, Jun 4, 2024 at 9:59 PM Kim, Dongwon
> >     <dongwon.kim@intel.com <mailto:dongwon.kim@intel.com>
> >      > <mailto:dongwon.kim@intel.com <mailto:dongwon.kim@intel.com>>>
> wrote:
> >
> >      > Xorg may not be going away soon, but it's used less and less. As
> >     one of
> >      > the developers, I am no longer running/testing it for a long
> time. I
> >      > wish we would just drop its support tbh.
> >
> >     There are features offered by Xorg that are not offered by Wayland
> >     compositors and again, we have customers that rely on these features.
> >     One of them is the ability to position the window via
> >     gtk_window_set_position(). There are strong arguments
> >     made on either side when it comes to window positioning:
> >
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247
> <
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247
> >
> >
> >     Until there is a way to do this with Wayland compositors, we have to
> >     unfortunately rely on Gnome + Xorg.
> >
> >
> > It's a smaller and smaller number of users. The potential/future users
> > are greater if we focus on Wayland.
>
> Right, but until Gtk + Wayland offers the same feature parity and
> customization as that of Gtk + Xorg, there will be distros/users that
> will keep it alive.
> >
> > Fwiw, GNOME (and RHEL) is set to drop Xorg support
> > (https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/98
> > <https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/98>)
>
> Doesn't look like it is going to happen anytime soon given the massive
> pushback.
>

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.


>
> >
> > Btw, there is a similar monitor-mapping functionality implemented in
> > virt-viewer/remote-viewer:
> > https://www.mankier.com/1/virt-viewer#Configuration
> > <https://www.mankier.com/1/virt-viewer#Configuration>. Is this
> something
> > that those users could use instead?
>
> It looks a bit similar and interesting but one difference is that our
> feature uses monitor labels such as DP-1, HDMI-2 which is a bit more
> intuitive. And, the other key difference is that our feature includes
>

Intuitive, perhaps. Discoverable and portable?

"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

Honestly, I don't support the idea of duplicating this effort in QEMU.
Kim, Dongwon June 13, 2024, 5:08 p.m. UTC | #8
Hi Marc-André,

On 6/12/2024 11:56 PM, Marc-André Lureau wrote:
> Hi
> 
> On Thu, Jun 13, 2024 at 3:34 AM Kim, Dongwon <dongwon.kim@intel.com 
> <mailto:dongwon.kim@intel.com>> wrote:
> 
>     On 6/11/2024 11:42 PM, Marc-André Lureau wrote:
>      > Hi
>      >
>      > On Tue, Jun 11, 2024 at 10:28 PM Kim, Dongwon
>     <dongwon.kim@intel.com <mailto:dongwon.kim@intel.com>
>      > <mailto:dongwon.kim@intel.com <mailto:dongwon.kim@intel.com>>> wrote:
>      >
>      >     Hi Marc-André,
>      >
>      >     On 6/5/2024 12:26 AM, Marc-André Lureau wrote:
>      >      > Hi
>      >      >
>      >      > On Tue, Jun 4, 2024 at 9:59 PM Kim, Dongwon
>      >     <dongwon.kim@intel.com <mailto:dongwon.kim@intel.com>
>     <mailto:dongwon.kim@intel.com <mailto:dongwon.kim@intel.com>>
>      >      > <mailto:dongwon.kim@intel.com
>     <mailto:dongwon.kim@intel.com> <mailto:dongwon.kim@intel.com
>     <mailto:dongwon.kim@intel.com>>>> wrote:
>      >
>      >      > Xorg may not be going away soon, but it's used less and
>     less. As
>      >     one of
>      >      > the developers, I am no longer running/testing it for a
>     long time. I
>      >      > wish we would just drop its support tbh.
>      >
>      >     There are features offered by Xorg that are not offered by
>     Wayland
>      >     compositors and again, we have customers that rely on these
>     features.
>      >     One of them is the ability to position the window via
>      >     gtk_window_set_position(). There are strong arguments
>      >     made on either side when it comes to window positioning:
>      >
>     https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247 <https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247> <https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247 <https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247>>
>      >
>      >     Until there is a way to do this with Wayland compositors, we
>     have to
>      >     unfortunately rely on Gnome + Xorg.
>      >
>      >
>      > It's a smaller and smaller number of users. The potential/future
>     users
>      > are greater if we focus on Wayland.
> 
>     Right, but until Gtk + Wayland offers the same feature parity and
>     customization as that of Gtk + Xorg, there will be distros/users that
>     will keep it alive.
>      >
>      > Fwiw, GNOME (and RHEL) is set to drop Xorg support
>      > (https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/98
>     <https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/98>
>      > <https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/98
>     <https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/98>>)
> 
>     Doesn't look like it is going to happen anytime soon given the massive
>     pushback.
> 
> 
> 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.
> 
> 
>      >
>      > Btw, there is a similar monitor-mapping functionality implemented in
>      > virt-viewer/remote-viewer:
>      > https://www.mankier.com/1/virt-viewer#Configuration
>     <https://www.mankier.com/1/virt-viewer#Configuration>
>      > <https://www.mankier.com/1/virt-viewer#Configuration
>     <https://www.mankier.com/1/virt-viewer#Configuration>>. Is this
>     something
>      > that those users could use instead?
> 
>     It looks a bit similar and interesting but one difference is that our
>     feature uses monitor labels such as DP-1, HDMI-2 which is a bit more
>     intuitive. And, the other key difference is that our feature includes
> 
> 
> Intuitive, perhaps. Discoverable and portable?
> 
>     "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>
> 
> 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 
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?

> 
> -- 
> Marc-André Lureau
Marc-André Lureau June 14, 2024, 8:41 a.m. UTC | #9
Hi

On Thu, Jun 13, 2024 at 9:08 PM Kim, Dongwon <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
> >
> >
> > 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
>
>
Kim, Dongwon June 14, 2024, 5:40 p.m. UTC | #10
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