>> 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 <[email protected]>
Sent: Monday, June 21, 2021 4:31 PM
To: Gerd Hoffmann <[email protected]>
Cc: Khor, Swee Aun <[email protected]>; Romli, Khairul Anuar
<[email protected]>; Kasireddy, Vivek <[email protected]>;
[email protected]; [email protected]
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 <[email protected]> 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.?
