Description of problem: kernel running is 2.6.27.5-117.fc10.i686 kvm is kvm-74-6.fc10.i386 When I run a disk img of rawhide via: qemu-kvm -k en-us -m 1024 rawhide.img a window pops up - I've set it in runlevel 3 only so just a VT. I login (as root in this case) and it seems like everything pauses whenever I leave the window or switch workspaces on the interface the kvm instance is running on. Here's a screenshot to explain what I'm seeing: http://skvidal.fedorapeople.org/misc/qemu-kvm-weirdness.png Is there a setting I'm missing or something like that?
Ah, sorry, this only seems to happen when I switch workspaces, not when I simply defocus the window.
Yeah, I noticed this a long time ago and thought it might have been intended behaviour with qemu's SDL interface. It isn't. Reproduce by running a guest, and in a shell on the console do "while true; do time sleep 10; done" Now, while the window is ungrabbed use Ctrl-Alt-RightArrow to switch to another workspace. Leave it for a while, come back and you'll see the guest had paused. with strace, it's looping with: select(7, [6], [6], NULL, NULL) = 1 (out [6]) writev(6, [{"\x1a\x01\x06\x00\x0d\x00\x80\x04\x00\x00\x01\x01\x0d\x00\x80\x04\x00\x00\x00\x00\x00\x00\x00\x00"..., 24}], 1) = 24 select(7, [6], [], NULL, NULL) = 1 (in [6]) read(6, "\x01\x03\xde\x59\x00\x00\x00\x00\x64\xb1\xa1\xbf\x20\x4d\xb4\x08\x18\x00\x00\x00\x18\x00\x00\x00\x68\xff\xf3\x08\x00x00\x00\x00"..., 4096) = 32 read(6, 0x8cb256c, 4096) = -1 EAGAIN (Resource temporarily unavailable) nanosleep({0, 100000000}, {0, 100000000}) = 0 select(7, [6], [6], NULL, NULL) = 1 (out [6]) req_type 0x1a means it's a GrabPointer request. status 0x3 in the GrabPointerReply is GrabNotViewable. backtrace: #1 0x002db996 in nanosleep () from /lib/libpthread.so.0 #2 0x00360b29 in SDL_Delay () from /usr/lib/libSDL-1.2.so.0 #3 0x003484bd in ?? () from /usr/lib/libSDL-1.2.so.0 #4 0x0034864e in ?? () from /usr/lib/libSDL-1.2.so.0 #5 0x003301f9 in ?? () from /usr/lib/libSDL-1.2.so.0 #6 0x080ce980 in sdl_grab_start () at sdl.c:289 #7 0x080cfb5d in sdl_refresh (ds=0x81c71a0) at sdl.c:462 #8 0x0804fab8 in gui_update (opaque=0x81c71a0) at /usr/src/debug/kvm-74/qemu/vl.c:7842 #9 0x08051220 in qemu_run_timers () at /usr/src/debug/kvm-74/qemu/vl.c:1217 #10 main_loop_wait (timeout=<value optimized out>) at /usr/src/debug/kvm-74/qemu/vl.c:8158 #11 0x08153884 in kvm_main_loop () at /usr/src/debug/kvm-74/qemu/qemu-kvm.c:588 #12 0x080599f0 in main_loop () at /usr/src/debug/kvm-74/qemu/vl.c:8182 It's clear what's happening - qemu sees the Ctrl-Alt and tries to grab. By that time we've already switched workspace and XGrabPointer returns GrabNotViewable. SDL_WM_GrabInput() then blocks until we come back to the workspace. Sure enough: #if 0 /* We'll wait here until we actually grab, otherwise behavior undefined */ for ( numtries = 0; numtries < 10; ++numtries ) { #else for ( ; ; ) { #endif result = XGrabPointer(SDL_Display, SDL_Window, True, 0, GrabModeAsync, GrabModeAsync, SDL_Window, None, CurrentTime); if ( result == GrabSuccess ) { break; } SDL_Delay(100); } if ( result != GrabSuccess ) { /* Uh, oh, what do we do here? */ ; } Attaching a fix for that to make it just return SDL_GRAB_OFF if we get GrabNotViewable. kvm needs a small fix to handle SDL_WM_GrabInput() returning SDL_GRAB_OFF, but it's not critical - without the kvm fix, the window just says it's grabbed when it's not.
Created attachment 329082 [details] SDL-1.2.13-grab-not-viewable.patch This should go upstream, but I'd appreciate someone familiar with the code looking over it first.
Created attachment 329083 [details] kvm-74-grabs-can-fail.patch I'm going to send this one to upstream QEMU right away.
Thanks for the quickfix.
Patch posted upstream: http://lists.libsdl.org/pipermail/sdl-libsdl.org/2009-January/068435.html
Last time I checked, this patch needs to be re-based against latest upstream SDL and re-submitted. AFAIR, the code has changed a good bit
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
(In reply to comment #6) > Patch posted upstream: > > http://lists.libsdl.org/pipermail/sdl-libsdl.org/2009-January/068435.html The URL is not valid now. Proper one is: http://lists.libsdl.org/pipermail/sdl-libsdl.org/2009-January/068274.html
http://lists.libsdl.org/pipermail/sdl-libsdl.org/2009-January/068267.html
I'm still seeing this in F14, and it's driving me nuts.. Reopening.
I worry about semantics provided to application (see comment #2 of bug #664771). I asked upstream for help (http://bugzilla.libsdl.org/show_bug.cgi?id=1155).
Upstream doesn't seem to be that worried about SDL 1.2 semantics. :(
Upstream did not say anything about SDL 1.2. Moreover it does not worry at all---they have not touch the code yet. IMHO SDL 1.3 implementation is worse. It does not return any status. It sometimes blocks, sometimes does not lock.
Are distribution-specific patches acceptable for this problem? (I'm not sure if this is allowed in Fedora/Redhat, but when I used Gentoo this was a common solution for when upstream didn't solve things in acceptable time.)
All Fedoras affected.
SDL-1.2.14-13.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/SDL-1.2.14-13.fc16
SDL-1.2.14-12.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/SDL-1.2.14-12.fc15
SDL-1.2.14-11.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/SDL-1.2.14-11.fc14
Package SDL-1.2.14-13.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing SDL-1.2.14-13.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/SDL-1.2.14-13.fc16 then log in and leave karma (feedback).
*** Bug 665329 has been marked as a duplicate of this bug. ***
Test case in https://bugzilla.redhat.com/attachment.cgi?id=470009
SDL-1.2.14-12.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
SDL-1.2.14-11.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
SDL-1.2.14-13.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
Upstream decided not to accept this change into version 1.2 to conserve API.