I just received a bugreport for bug 197276. This is bug is about the display going black with just gcompris's custom mouse cursos showing when the screensaver kicks in. After some experimenting (I only had xscreensaver on my box), it turns out that this only happens when gnome-screensaver is used. The problem is that gcompris by default runs fullscreen at a resolution of 800x600. To get this resolution gcompris uses xf86vidmode, which brings the problem that we do get a viewport of 800x600 but not a desktop of 800x600. To stop the viewport from panning away from our 800x600 window we grab the mouse and confine it to the 800x600 window. Notice that gcompris is not alona all fullscreen SDL and allegro applications do the same. AFAIK all applications which chance the resolution when going fullscreen do this as its the only way. So far no problem really untill gnome-screensaver kicks in, it seems to wait forver while trying to grab the mouse, resulting in a black screen with gcompris's customcursor. It does not respond to mouse movements, nor to keyboard presses to end the screensaver, effectivly hanging the computer. xscreensaver does have the problem of not being able to change (blank) the mouse cursor when the mouse is grabbed and not responding to mouse movements. But it does start its saver and can be get out of saving mode with the keyboard just fine. To reproduce: -install gcompris -run it -wait for the screensaver to kick in
So the problem is ... in gs_grab_grab_window () we have this: if (kstatus != GDK_GRAB_SUCCESS) { /* Do not blank without a kbd grab. */ return FALSE; } So it continues if the mouse grab failed (just like xscreensaver does), but later in gs_grab_move_to_window () it does this: do { result = gs_grab_move_mouse (grab, window, screen, hide_cursor); gdk_flush (); } while (!result); So it ultimately just sits there looping waiting for the mouse grab. There are two ways we could approach this I guess. 1) make the move_mouse call optional, too. I think this won't work well though. We really need mouse events for some parts of the lock dialog to work correctly I think. 2) make the screensaver fail when mstatus isn't a GDK_GRAB_SUCCESS too. I think 2 is the best way to go. Taking a pointer grab to confine the pointer isn't really very nice of gcompris. I guess another approach would be set up some input-only windows at the edges of the viewport and check for mouse enter notify events to see when the viewport is about to scroll. On the other hand, we don't really want to show a lock dialog at 800x600 resolution anyway. Really, gcompris should be upscaling its contents to fit in the users resolution instead of changing the resolution.
(In reply to comment #1) > Really, gcompris should be upscaling its contents to fit in the users resolution > instead of changing the resolution. gcompris has long been fixed to work with gnome-screensaver, as soon as it receives a focus out event it switches from fullscreen-mode to windowed mode, both restoring the original resolution and releasing the mouse. However this should still be fixed in gnome-screensaver, you can trigger this too by (for example) clicking on a gtk drop down menu and then not choosing anything atleast I think I know the mouse gets grabbed during the click, but maybe its gets ungrabbed on the button up. Also all games that I know of (and I maintain close to a 100 games in FE) use the same technique for fullscreen, xf86vidmode + grabbing the mouse to lock the viewport, this aint pretty but it is the best X has to offer. Atleast all games using SDL, allegro and ClanLib use this. I'm pretty sure about this because both allegro and ClanLib had sub optimal fullscreen handling (which did already grab the mouse) so I've rewritten their fullscreen handling to be more like SDL's (which I used for inspiration).
I actually tested the reproduction instructions before investigating the code and the problem still seems to be present with rawhide. There is no doubt there is a bug in gnome-screensaver. It needs to figure out whether mouse grabs are optional or required. If required then it shouldn't allow the screen to lock in the first place if the mouse is already grabbed. If optional then that while loop I mentioned above needs to be changed. When a menu is on screen we have to have a pointer grab in place, otherwise clicking outside of the menu wouldn't make it go away. Perhaps games should be inhibiting the screensaver when they're running?
Created attachment 151447 [details] I think something like this is the way to go
I agree. Can you commit that to head after also changing that comment before the return FALSE? Thanks Ray.
sure
(In reply to comment #3) > I actually tested the reproduction instructions before investigating the code > and the problem still seems to be present with rawhide. > ??? I just tried it too, and it works fine, gcompris restores the resolution an ungrabs the mouse. I assume you are running under gnome :) Can you try again, without any gnome-screen-saver-command tricks? (I just set the timeout to 1 minute). I'm interested as I maintain gcompris and I wrote the workaround patch.
so what I did was, 1) run gnome-screensaver-preferences and set timeout to 1 minute 2) pkill gnome-screen 3) screen 4) gnome-screensaver --no-daemon --debug 5) gcompris & 6) got a snack from the kitchen When I got back the screen was black, with the gcompris pointer in place. No dialog came up when I wiggled the mouse. I pressed ctrl-alt-f1, logged in, and did screen -x. gnome-screensaver said it was trying to grab the pointer over and over again.
(In reply to comment #8) > so what I did was, > > 1) run gnome-screensaver-preferences and set timeout to 1 minute > 2) pkill gnome-screen > 3) screen > 4) gnome-screensaver --no-daemon --debug > 5) gcompris & > 6) got a snack from the kitchen > > When I got back the screen was black, with the gcompris pointer in place. No > dialog came up when I wiggled the mouse. > > I pressed ctrl-alt-f1, logged in, and did screen -x. gnome-screensaver said it > was trying to grab the pointer over and over again. Thanks for looking into this, thats really weird, here is what I did: 1) run gnome-screensaver-preferences and set timeout to 1 minute 2) gcompris 3) wait 1 minute 4) watch the screensaver 5) press a key, enter password, back in gcompris This is a x86_64 machine with a rawhide of about 10 days old, updating as we speak, what does rpm -q gcompris say on your system?
gcompris-8.2.2-2.fc7.i386
(In reply to comment #10) > gcompris-8.2.2-2.fc7.i386 Yes thats the same version as me, I've fully updated my system and I still cannot reproduce this. One last question, what screensaver are you using? Maybe that makes a difference. After that I'll leave this rest either way.
it doesn't seem to matter which screensaver I use. Right now I'm using Floating Feet.