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