Gerd Hoffmann <kra...@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.?
