1 files changed, 54 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/other/1216368 b/results/classifier/zero-shot/108/other/1216368
new file mode 100644
index 000000000..75f8fb275
--- /dev/null
+++ b/results/classifier/zero-shot/108/other/1216368
@@ -0,0 +1,54 @@
+semantic: 0.815
+graphic: 0.705
+device: 0.702
+other: 0.691
+socket: 0.666
+debug: 0.601
+files: 0.554
+performance: 0.550
+PID: 0.515
+vnc: 0.487
+boot: 0.449
+network: 0.391
+permissions: 0.365
+KVM: 0.293
+
+unsupported screen resolution crashes sdl-qemu
+
+if the (windows) guest sets a screen resolution that the SDL backend does not support,
+qemu does an exit(1).
+with this fix, the the resolution is still wrong (only part of the desktop is displayed),
+but qemu keeps running and the guest can auto-revert the video mode:
+
+ui/sdl.c:do_sdl_resize()
+    SDL_Surface * tmp_screen;
+    tmp_screen = SDL_SetVideoMode(width, height, bpp, flags);
+    if (!tmp_screen) {
+//      fprintf(stderr, "Could not open SDL display (%dx%dx%d): %s\n", width, 
+//              height, bpp, SDL_GetError());
+//      exit(1);
+    } else {
+        real_screen = tmp_screen;
+    }
+
+Sorry, a little confusion what's the problem you want to solve?
+
+its in the first sentence. let me rephrase: the (windows) guest can select some screen resolution which SDL cannot
+provide. what happens is that qemu quits without giving the quest a chance to shut down. thats like having a monitor
+that crashes windows when it doesnt support the video mode.
+
+Yes, it is a bug. It should go back to the previous setting if the new screen resolution falied.
+I will send a patch later. 
+
+Thanks.
+
+Patch posted:
+
+http://patchwork.ozlabs.org/patch/270084/
+
+this patch does solve the problem
+
+Patch has been included here a while ago already:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=898ae2846de4dcb1
+... so this ticket could now be marked as fixed.
+