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

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

[dongwon.kim]

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(-)

-- 
2.34.1

[RFC PATCH v2 1/2] ui/gtk: Factor out tab window creation into a separate

[dongwon.kim]

From: Vivek Kasireddy <vivek.kasireddy@intel.com>

Pull the code that creates a new window associated with a notebook
tab into a separate function. This new function can be useful not
just when user wants to detach a tab but also in the future when
a new window creation is needed in other scenarios.

Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Daniel P. Berrangé <berrange@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
Signed-off-by: Dongwon Kim <dongwon.kim@intel.com>
---
 ui/gtk.c | 65 +++++++++++++++++++++++++++++++-------------------------
 1 file changed, 36 insertions(+), 29 deletions(-)

diff --git a/ui/gtk.c b/ui/gtk.c
index 93b13b7a30..3bc84090c8 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -1396,6 +1396,41 @@ static gboolean gd_win_grab(void *opaque)
     return TRUE;
 }
 
+static void gd_tab_window_create(VirtualConsole *vc)
+{
+    GtkDisplayState *s = vc->s;
+
+    gtk_widget_set_sensitive(vc->menu_item, false);
+    vc->window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
+#if defined(CONFIG_OPENGL)
+    if (vc->gfx.esurface) {
+        eglDestroySurface(qemu_egl_display, vc->gfx.esurface);
+        vc->gfx.esurface = NULL;
+    }
+    if (vc->gfx.ectx) {
+        eglDestroyContext(qemu_egl_display, vc->gfx.ectx);
+        vc->gfx.ectx = NULL;
+    }
+#endif
+    gd_widget_reparent(s->notebook, vc->window, vc->tab_item);
+
+    g_signal_connect(vc->window, "delete-event",
+                     G_CALLBACK(gd_tab_window_close), vc);
+    gtk_widget_show_all(vc->window);
+
+    if (qemu_console_is_graphic(vc->gfx.dcl.con)) {
+        GtkAccelGroup *ag = gtk_accel_group_new();
+        gtk_window_add_accel_group(GTK_WINDOW(vc->window), ag);
+
+        GClosure *cb = g_cclosure_new_swap(G_CALLBACK(gd_win_grab),
+                                           vc, NULL);
+        gtk_accel_group_connect(ag, GDK_KEY_g, HOTKEY_MODIFIERS, 0, cb);
+    }
+
+    gd_update_geometry_hints(vc);
+    gd_update_caption(s);
+}
+
 static void gd_menu_untabify(GtkMenuItem *item, void *opaque)
 {
     GtkDisplayState *s = opaque;
@@ -1407,35 +1442,7 @@ static void gd_menu_untabify(GtkMenuItem *item, void *opaque)
                                        FALSE);
     }
     if (!vc->window) {
-        gtk_widget_set_sensitive(vc->menu_item, false);
-        vc->window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
-#if defined(CONFIG_OPENGL)
-        if (vc->gfx.esurface) {
-            eglDestroySurface(qemu_egl_display, vc->gfx.esurface);
-            vc->gfx.esurface = NULL;
-        }
-        if (vc->gfx.ectx) {
-            eglDestroyContext(qemu_egl_display, vc->gfx.ectx);
-            vc->gfx.ectx = NULL;
-        }
-#endif
-        gd_widget_reparent(s->notebook, vc->window, vc->tab_item);
-
-        g_signal_connect(vc->window, "delete-event",
-                         G_CALLBACK(gd_tab_window_close), vc);
-        gtk_widget_show_all(vc->window);
-
-        if (qemu_console_is_graphic(vc->gfx.dcl.con)) {
-            GtkAccelGroup *ag = gtk_accel_group_new();
-            gtk_window_add_accel_group(GTK_WINDOW(vc->window), ag);
-
-            GClosure *cb = g_cclosure_new_swap(G_CALLBACK(gd_win_grab),
-                                               vc, NULL);
-            gtk_accel_group_connect(ag, GDK_KEY_g, HOTKEY_MODIFIERS, 0, cb);
-        }
-
-        gd_update_geometry_hints(vc);
-        gd_update_caption(s);
+        gd_tab_window_create(vc);
     }
 }
 
-- 
2.34.1

[PATCH RFC v2 2/2] ui/gtk: Add a new parameter to assign connectors/monitors

[dongwon.kim]

From: Vivek Kasireddy <vivek.kasireddy@intel.com>

The new parameter named "connector" can be used to assign physical
monitors/connectors to individual GFX VCs such that when the monitor
is connected or hot-plugged, the associated GTK window would be
moved to it. If the monitor is disconnected or unplugged, the
associated GTK window would be hidden and a relevant disconnect
event would be sent to the Guest.

One usage example is here:

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

With this, the first graphic virtual console will be placed on DP-1
display, 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

Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Daniel P. Berrangé <berrange@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
Signed-off-by: Dongwon Kim <dongwon.kim@intel.com>
---
 qapi/ui.json     |  25 ++++-
 include/ui/gtk.h |   1 +
 ui/gtk.c         | 250 +++++++++++++++++++++++++++++++++++++++++++++++
 qemu-options.hx  |   4 +
 4 files changed, 279 insertions(+), 1 deletion(-)

diff --git a/qapi/ui.json b/qapi/ui.json
index f610bce118..46ed9e76fc 100644
--- a/qapi/ui.json
+++ b/qapi/ui.json
@@ -1335,13 +1335,36 @@
 # @show-menubar: Display the main window menubar.  Defaults to "on".
 #     (Since 8.0)
 #
+# @connectors: A list of physical monitor/connector names where the
+#     GTK windows containing the respective GFX VCs (virtual consoles)
+#     are to be placed. The connector names should be provided as
+#     a string, with each name separated by a colon
+#     (e.g., DP-1:DP-2:HDMI-1:HDMI-2). Each connector name in the
+#     string will be used as a label for each VC in order.
+#     VCs can be skipped by leaving an empty spot between colons
+#     (e.g., DP-1::HDMI-2). If a connector name is not provided for
+#     a VC, that VC will not be placed on any physical display and
+#     the guest will see it as disconnected. If a valid connector name
+#     is provided for a VC but its display cable is not plugged in
+#     when the guest is launched, the VC will not be displayed initially.
+#     It will appear on the display when the cable is plugged in
+#     (hot-plug). If the cable is disconnected, the VC will be hidden
+#     and the guest will see its virtual display as disconnected.
+#     Multiple VCs can share the same connector name. In this case,
+#     all VCs with that name will be displayed on the same physical
+#     monitor. However, a single VC cannot have multiple connector
+#     names.
+#
+#     (Since 9.1)
+#
 # Since: 2.12
 ##
 { 'struct'  : 'DisplayGTK',
   'data'    : { '*grab-on-hover' : 'bool',
                 '*zoom-to-fit'   : 'bool',
                 '*show-tabs'     : 'bool',
-                '*show-menubar'  : 'bool'  } }
+                '*show-menubar'  : 'bool',
+                '*connectors'    : 'str' } }
 
 ##
 # @DisplayEGLHeadless:
diff --git a/include/ui/gtk.h b/include/ui/gtk.h
index aa3d637029..3f78ee5996 100644
--- a/include/ui/gtk.h
+++ b/include/ui/gtk.h
@@ -83,6 +83,7 @@ typedef struct VirtualConsole {
     GtkWidget *menu_item;
     GtkWidget *tab_item;
     GtkWidget *focus;
+    GdkMonitor *monitor;
     VirtualConsoleType type;
     union {
         VirtualGfxConsole gfx;
diff --git a/ui/gtk.c b/ui/gtk.c
index 3bc84090c8..dc356e1dcf 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -38,6 +38,7 @@
 #include "qemu/cutils.h"
 #include "qemu/error-report.h"
 #include "qemu/main-loop.h"
+#include "qemu/option.h"
 
 #include "ui/console.h"
 #include "ui/gtk.h"
@@ -1446,6 +1447,248 @@ static void gd_menu_untabify(GtkMenuItem *item, void *opaque)
     }
 }
 
+static void gd_ui_mon_enable(VirtualConsole *vc)
+{
+    GdkWindow *window = gtk_widget_get_window(vc->gfx.drawing_area);
+    QemuUIInfo info;
+
+    if (!dpy_ui_info_supported(vc->gfx.dcl.con)) {
+        return;
+    }
+
+    info = *dpy_get_ui_info(vc->gfx.dcl.con);
+    info.width = gdk_window_get_width(window);
+    info.height = gdk_window_get_height(window);
+    dpy_set_ui_info(vc->gfx.dcl.con, &info, false);
+}
+
+static void gd_ui_mon_disable(VirtualConsole *vc)
+{
+    QemuUIInfo info;
+
+    if (!dpy_ui_info_supported(vc->gfx.dcl.con)) {
+        return;
+    }
+
+    info = *dpy_get_ui_info(vc->gfx.dcl.con);
+    info.width = 0;
+    info.height = 0;
+    dpy_set_ui_info(vc->gfx.dcl.con, &info, false);
+}
+
+static void gd_window_show_on_monitor(GdkDisplay *dpy, VirtualConsole *vc,
+                                      gint monitor_num)
+{
+    GtkDisplayState *s = vc->s;
+    GdkMonitor *monitor = gdk_display_get_monitor(dpy, monitor_num);
+    GdkRectangle geometry;
+    if (!vc->window) {
+        gd_tab_window_create(vc);
+    }
+
+    gdk_window_show(gtk_widget_get_window(vc->window));
+    gd_update_windowsize(vc);
+    gdk_monitor_get_geometry(monitor, &geometry);
+
+    gtk_window_move(GTK_WINDOW(vc->window), geometry.x, geometry.y);
+
+    if (s->opts->has_full_screen && s->opts->full_screen) {
+        gtk_widget_set_size_request(vc->gfx.drawing_area, -1, -1);
+        gtk_window_fullscreen(GTK_WINDOW(vc->window));
+    } else if ((s->window == vc->window) && s->full_screen) {
+        gd_menu_show_tabs(GTK_MENU_ITEM(s->show_tabs_item), s);
+        if (gtk_check_menu_item_get_active(
+                    GTK_CHECK_MENU_ITEM(s->show_menubar_item))) {
+            gtk_widget_show(s->menu_bar);
+        }
+        s->full_screen = false;
+    }
+
+    vc->monitor = monitor;
+    gd_ui_mon_enable(vc);
+    gd_update_cursor(vc);
+}
+
+static int gd_monitor_lookup(GdkDisplay *dpy, char *label)
+{
+    GdkMonitor *monitor;
+    int total_monitors = gdk_display_get_n_monitors(dpy);
+    const char *model;
+    int i;
+
+    for (i = 0; i < total_monitors; i++) {
+        monitor = gdk_display_get_monitor(dpy, i);
+        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;
+        }
+
+        if (monitor && !g_strcmp0(model, label)) {
+            return i;
+        }
+    }
+    return -1;
+}
+
+static gboolean gd_vc_is_misplaced(GdkDisplay *dpy, GdkMonitor *monitor,
+                                   VirtualConsole *vc)
+{
+    GdkWindow *window = gtk_widget_get_window(vc->gfx.drawing_area);
+    GdkMonitor *mon = gdk_display_get_monitor_at_window(dpy, window);
+    const char *model = gdk_monitor_get_model(monitor);
+
+    if (!vc->monitor) {
+        if (!g_strcmp0(model, vc->label)) {
+            return TRUE;
+        }
+    } else {
+        if (mon && mon != vc->monitor) {
+            return TRUE;
+        }
+    }
+    return FALSE;
+}
+
+static void gd_vc_windows_reposition(GdkDisplay *dpy, GtkDisplayState *s)
+{
+    VirtualConsole *vc;
+    GdkMonitor *monitor;
+    gint monitor_num;
+    int i;
+
+    for (i = 0; i < s->nb_vcs; i++) {
+        vc = &s->vc[i];
+        if (vc->label) {
+            monitor_num = gd_monitor_lookup(dpy, vc->label);
+            if (monitor_num >= 0) {
+                monitor = gdk_display_get_monitor(dpy, monitor_num);
+                if (gd_vc_is_misplaced(dpy, monitor, vc)) {
+                    gd_window_show_on_monitor(dpy, vc, monitor_num);
+                }
+            } else if (vc->monitor) {
+                vc->monitor = NULL;
+                gd_ui_mon_disable(vc);
+
+                /* if window exist, hide it */
+                if (vc->window) {
+                    gdk_window_hide(gtk_widget_get_window(vc->window));
+                }
+            }
+        }
+    }
+}
+
+static void gd_monitors_reset_timer(void *opaque)
+{
+    GtkDisplayState *s = opaque;
+    GdkDisplay *dpy = gdk_display_get_default();
+
+    gd_vc_windows_reposition(dpy, s);
+}
+
+static void gd_monitors_changed(GdkScreen *scr, void *opaque)
+{
+    GtkDisplayState *s = opaque;
+    QEMUTimer *mon_reset_timer;
+
+    /* This timer setup ensures the compositor finishes placing
+     * all QEMU windows after a display hot plug event
+     * before QEMU rearranges the windows based on connectors
+     * setting.
+     */
+    mon_reset_timer = timer_new_ms(QEMU_CLOCK_REALTIME,
+                                   gd_monitors_reset_timer, s);
+    timer_mod(mon_reset_timer,
+              qemu_clock_get_ms(QEMU_CLOCK_REALTIME) + 2000);
+}
+
+static VirtualConsole *gd_next_gfx_vc(GtkDisplayState *s)
+{
+    VirtualConsole *vc;
+    int i;
+
+    for (i = 0; i < s->nb_vcs; i++) {
+        vc = &s->vc[i];
+        if (vc->type == GD_VC_GFX &&
+            qemu_console_is_graphic(vc->gfx.dcl.con) &&
+            !vc->label) {
+            return vc;
+        }
+    }
+    return NULL;
+}
+
+static void gd_vc_free_labels(GtkDisplayState *s)
+{
+    VirtualConsole *vc;
+    int i;
+
+    for (i = 0; i < s->nb_vcs; i++) {
+        vc = &s->vc[i];
+        if (vc->type == GD_VC_GFX &&
+            qemu_console_is_graphic(vc->gfx.dcl.con)) {
+            g_free(vc->label);
+            vc->label = NULL;
+        }
+    }
+}
+
+static void gd_connectors_init(GdkDisplay *dpy, GtkDisplayState *s)
+{
+    VirtualConsole *vc;
+    gint monitor_num;
+    gboolean first_vc = TRUE;
+    char *conn = s->opts->u.gtk.connectors;
+    char *this, *ptr;
+
+    gtk_notebook_set_show_tabs(GTK_NOTEBOOK(s->notebook), FALSE);
+    gtk_check_menu_item_set_active(GTK_CHECK_MENU_ITEM(s->grab_item),
+                                   FALSE);
+    gd_vc_free_labels(s);
+
+    ptr = conn;
+
+    while (ptr < conn + strlen(conn)) {
+        this = strchr(ptr, ':');
+
+        vc = gd_next_gfx_vc(s);
+        if (!vc) {
+            break;
+        }
+        if (first_vc) {
+            vc->window = s->window;
+            first_vc = FALSE;
+        }
+
+        if (this == NULL) {
+            vc->label = g_strdup(ptr);
+        } else {
+            vc->label = g_strndup(ptr, this - ptr);
+        }
+
+        monitor_num = gd_monitor_lookup(dpy, vc->label);
+        if (monitor_num >= 0) {
+            gd_window_show_on_monitor(dpy, vc, monitor_num);
+        } else {
+            gd_ui_mon_disable(vc);
+
+            if (vc->window) {
+                gdk_window_hide(gtk_widget_get_window(vc->window));
+            }
+        }
+
+        if (this == NULL) {
+            break;
+        } else {
+            ptr = this + 1;
+        }
+    }
+}
+
 static void gd_menu_show_menubar(GtkMenuItem *item, void *opaque)
 {
     GtkDisplayState *s = opaque;
@@ -2102,6 +2345,10 @@ static void gd_connect_signals(GtkDisplayState *s)
                      G_CALLBACK(gd_menu_grab_input), s);
     g_signal_connect(s->notebook, "switch-page",
                      G_CALLBACK(gd_change_page), s);
+    if (s->opts->u.gtk.connectors) {
+        g_signal_connect(gdk_screen_get_default(), "monitors-changed",
+                         G_CALLBACK(gd_monitors_changed), s);
+    }
 }
 
 static GtkWidget *gd_create_menu_machine(GtkDisplayState *s)
@@ -2489,6 +2736,9 @@ static void gtk_display_init(DisplayState *ds, DisplayOptions *opts)
         opts->u.gtk.show_tabs) {
         gtk_menu_item_activate(GTK_MENU_ITEM(s->show_tabs_item));
     }
+    if (s->opts->u.gtk.connectors) {
+        gd_connectors_init(window_display, s);
+    }
 #ifdef CONFIG_GTK_CLIPBOARD
     gd_clipboard_init(s);
 #endif /* CONFIG_GTK_CLIPBOARD */
diff --git a/qemu-options.hx b/qemu-options.hx
index 8ca7f34ef0..ebc7181472 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2099,6 +2099,7 @@ DEF("display", HAS_ARG, QEMU_OPTION_display,
     "-display gtk[,full-screen=on|off][,gl=on|off][,grab-on-hover=on|off]\n"
     "            [,show-tabs=on|off][,show-cursor=on|off][,window-close=on|off]\n"
     "            [,show-menubar=on|off][,zoom-to-fit=on|off]\n"
+    "            [,connectors=conn1:conn2:...:connN]]\n"
 #endif
 #if defined(CONFIG_VNC)
     "-display vnc=<display>[,<optargs>]\n"
@@ -2195,6 +2196,9 @@ SRST
         ``zoom-to-fit=on|off`` : Expand video output to the window size,
                                  defaults to "off"
 
+        ``connectors=conn1:conn2...`` : VC to connector mappings to display the VC
+                                        window on a specific monitor
+
     ``curses[,charset=<encoding>]``
         Display video output via curses. For graphics device models
         which support a text mode, QEMU can display this output using a
-- 
2.34.1

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

[Marc-André Lureau]

[-- Attachment #1: Type: text/plain, Size: 2053 bytes --]

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?

-- 
Marc-André Lureau

[-- Attachment #2: Type: text/html, Size: 2807 bytes --]

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

[Kim, Dongwon]

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

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

[Marc-André Lureau]

[-- Attachment #1: Type: text/plain, Size: 4066 bytes --]

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?



-- 
Marc-André Lureau

[-- Attachment #2: Type: text/html, Size: 6066 bytes --]

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

[Kim, Dongwon]

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

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

[Marc-André Lureau]

[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]

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?


-- 
Marc-André Lureau

[-- Attachment #2: Type: text/html, Size: 2574 bytes --]

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

[Kim, Dongwon]

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

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

[Marc-André Lureau]

[-- Attachment #1: Type: text/plain, Size: 3528 bytes --]

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.

-- 
Marc-André Lureau

[-- Attachment #2: Type: text/html, Size: 6164 bytes --]

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

[Kim, Dongwon]

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

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

[Marc-André Lureau]

[-- Attachment #1: Type: text/plain, Size: 1665 bytes --]

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
>
>

-- 
Marc-André Lureau

[-- Attachment #2: Type: text/html, Size: 2855 bytes --]

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

[Kim, Dongwon]

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