RE: [PATCH v2] ui/gtk: Allow user to select monitor number to display qemu in full screen through new gtk display option

[Khor, Swee Aun]

>> sweeaun: Based on my observation, when specific monitor device disconnected 
>> after QEMU launched on it, QEMU application will not be visible but QEMU 
>> application still running and screen framebuffer size is not being changed 
>> at all. QEMU application will be visible once you connect back the monitor. 
>
> Well, that probably depends on the display server and might even be 
> configurable.  I've seen different ways to handle that, most common 
> ones being (a) do nothing or (b) trying move all windows to the 
> monitor which is still connected.
>
> I don't think qemu has to worry much here, and trying to automatically 
> adapt to hot-plugged monitors might even have bad interactions with 
> whatever the display server is going to do.

I'm concerned there is a TOCTTOU issue:

    if (opts->u.gtk.has_monitor) {
        int n_monitor;
1.      n_monitor = gdk_display_get_n_monitors(window_display);

2.      if ((opts->u.gtk.monitor <= n_monitor) &&
            (opts->u.gtk.monitor > 0)) {
            GdkScreen *gdk_screen;
            gdk_screen = gdk_display_get_default_screen(window_display);
3.          gtk_window_fullscreen_on_monitor(GTK_WINDOW(s->window), gdk_screen,
                                             (opts->u.gtk.monitor - 1));
        } else {
            fprintf(stderr, "Invalid GTK monitor argument\n");
        }
    }

If monitors can go at any time, then the check 2. cannot ensure we pass a valid 
monitor number at 3.

I asked what happens when we pass an invalid monitor number.  I'm not sure I 
understand sweeaun's answer.

If what happens is sane, then why have check 2.?

sweeaun: Sorry, I misunderstood your question, I thought your question is about 
what happened if monitor disconnected after the QEMU launched.
You are right, monitor could be disconnected in between 1 and 3. If invalid 
monitor passed into gtk_window_fullscreen_on_monitor then QEMU window will just 
be launched as normal without full screen and not the monitor that user 
specify.  I should check whether full screen has been successful taken in place 
since gtk_window_fullscreen_on_monitor function always return void.  

Regards,
SweeAun

-----Original Message-----
From: Markus Armbruster <armbru@redhat.com> 
Sent: Monday, June 21, 2021 4:31 PM
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Khor, Swee Aun <swee.aun.khor@intel.com>; Romli, Khairul Anuar 
<khairul.anuar.romli@intel.com>; Kasireddy, Vivek <vivek.kasireddy@intel.com>; 
eblake@redhat.com; qemu-devel@nongnu.org
Subject: Re: [PATCH v2] ui/gtk: Allow user to select monitor number to display 
qemu in full screen through new gtk display option

Gerd Hoffmann <kraxel@redhat.com> writes:


[...]

>> sweeaun: Based on my observation, when specific monitor device disconnected 
>> after QEMU launched on it, QEMU application will not be visible but QEMU 
>> application still running and screen framebuffer size is not being changed 
>> at all. QEMU application will be visible once you connect back the monitor. 
>
> Well, that probably depends on the display server and might even be 
> configurable.  I've seen different ways to handle that, most common 
> ones being (a) do nothing or (b) trying move all windows to the 
> monitor which is still connected.
>
> I don't think qemu has to worry much here, and trying to automatically 
> adapt to hot-plugged monitors might even have bad interactions with 
> whatever the display server is going to do.

I'm concerned there is a TOCTTOU issue:

    if (opts->u.gtk.has_monitor) {
        int n_monitor;
1.      n_monitor = gdk_display_get_n_monitors(window_display);

2.      if ((opts->u.gtk.monitor <= n_monitor) &&
            (opts->u.gtk.monitor > 0)) {
            GdkScreen *gdk_screen;
            gdk_screen = gdk_display_get_default_screen(window_display);
3.          gtk_window_fullscreen_on_monitor(GTK_WINDOW(s->window), gdk_screen,
                                             (opts->u.gtk.monitor - 1));
        } else {
            fprintf(stderr, "Invalid GTK monitor argument\n");
        }
    }

If monitors can go at any time, then the check 2. cannot ensure we pass a valid 
monitor number at 3.

I asked what happens when we pass an invalid monitor number.  I'm not sure I 
understand sweeaun's answer.

If what happens is sane, then why have check 2.?