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....@intel.com
<mailto: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>
> <mailto:dongwon....@intel.com <mailto:dongwon....@intel.com>>> wrote:
>
> From: Dongwon Kim <dongwon....@intel.com
<mailto:dongwon....@intel.com> <mailto: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>
>
<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
