Bug 197452

Summary: gnome-screensaver fails when an application has the mousegrabbed, effectivly locking up the box.
Product: [Fedora] Fedora Reporter: Hans de Goede <hdegoede>
Component: gnome-screensaverAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED RAWHIDE QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: rawhideCC: jmccann
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-04-02 17:35:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
I think something like this is the way to go none

Description Hans de Goede 2006-07-01 21:28:19 UTC
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

Comment 1 Ray Strode [halfline] 2007-04-02 16:31:59 UTC
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.

Comment 2 Hans de Goede 2007-04-02 16:45:00 UTC
(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).



Comment 3 Ray Strode [halfline] 2007-04-02 17:00:44 UTC
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?

Comment 4 Ray Strode [halfline] 2007-04-02 17:17:00 UTC
Created attachment 151447 [details]
I think something like this is the way to go

Comment 5 jmccann 2007-04-02 17:23:50 UTC
I agree.  Can you commit that to head after also changing that comment before
the return FALSE?  Thanks Ray.

Comment 6 Ray Strode [halfline] 2007-04-02 17:34:37 UTC
sure

Comment 7 Hans de Goede 2007-04-02 19:53:10 UTC
(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.


Comment 8 Ray Strode [halfline] 2007-04-02 20:16:37 UTC
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.

Comment 9 Hans de Goede 2007-04-02 20:24:51 UTC
(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?



Comment 10 Ray Strode [halfline] 2007-04-02 20:27:59 UTC
gcompris-8.2.2-2.fc7.i386

Comment 11 Hans de Goede 2007-04-03 06:34:12 UTC
(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.


Comment 12 Ray Strode [halfline] 2007-04-03 14:19:59 UTC
it doesn't seem to matter which screensaver I use.  Right now I'm using Floating
Feet.