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

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

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