Hi On Fri, May 31, 2024 at 11:00 PM <dongwon....@intel.com> wrote:
> From: Dongwon Kim <dongwon....@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
