Hi On Tue, Jun 4, 2024 at 9:59 PM Kim, Dongwon <dongwon....@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....@intel.com > > <mailto:dongwon....@intel.com>> wrote: > > > > From: Dongwon Kim <dongwon....@intel.com <mailto: > dongwon....@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
