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-screensaver | Assignee: | Ray Strode [halfline] <rstrode> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | |||||
Severity: | high | Docs Contact: | |||||
Priority: | high | ||||||
Version: | rawhide | CC: | 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
Hans de Goede
2006-07-01 21:28:19 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. (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. |