Bug 300321 - gnome screensaver does not detect input when fullscreen sdl game is running
gnome screensaver does not detect input when fullscreen sdl game is running
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gnome-screensaver (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: jmccann
Fedora Extras Quality Assurance
: Triaged
: 452433 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-21 09:53 EDT by drago01
Modified: 2015-01-14 18:20 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 00:58:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output of gnome-screensaver --no-daemon --debug (16.26 KB, text/plain)
2007-09-21 10:04 EDT, drago01
no flags Details

  None (edit)
Description drago01 2007-09-21 09:53:48 EDT
Description of problem:
When playing a fullscreen sdl game like quake3, nexuiz or ut2004
gnome-screensaver starts during the game and locks the screen. The games are
played via mouse and keyboard so there is input all the time but
gnome-screensaver thinks there is no input and kicks in. 

Version-Release number of selected component (if applicable):

gnome-screensaver-2.18.2-2.fc7

How reproducible:

always

Steps to Reproduce:
1. make sure gnome-screensaver is enabled
2. start one of the said games
3. play it until gnome-screensaver kicks in
  
Actual results:

gnome-screensaver is started during the game


Expected results:

gnome-screensaver should do nothing as long as there is input like it does
outside of the game.

Additional Info:

The screensaver timeout was set to 10.
Comment 1 drago01 2007-09-21 10:04:51 EDT
Created attachment 202201 [details]
output of  gnome-screensaver --no-daemon --debug
Comment 2 Ray Strode [halfline] 2008-03-08 15:39:23 EST
So I guess things probably go down like this:

1) game needs to run at lower resolution than desktop
2) game uses vid mode extension to lower output resolution (but keep old
resolution as virtual size).  This would be comparable to ctrl+alt+plus/minus
3) game ensures it's fully on screen
4) game sets up a pointer grab/grab window to prevent the mouse point from
hitting the edge of the on screen area and triggering X's annoying pan-and-scan
behavior
5) gnome-screensaver now doesn't know the user is using the computer, because
the active pointer grab the game set up is stealing all the events.
6) after the idle timeout period gnome-screensaver tries to lock screen.  It
can't because of the active grab (the screensaver itself needs to take a grab
and won't be able to lock otherwise)
7) gnome-screensaver tries a few times to get the grab hoping it's just
temporarily unavailable.
8) at some point the game releases the grab, not sure why, but when it does,
*bam* screensaver kicks in.
Comment 3 Ray Strode [halfline] 2008-03-08 15:44:30 EST
maybe the solution is, "If we get AlreadyGrabbed treat it as user activity and
cancel any pending lock operations"

The rationale being, we won't know what the user is doing when there is a grab
in place, so we should be conservative and assume the user is doing something.

Alternatively, maybe we should switch to using screensaver extension for idle
reporting (independent of using the screen saver window mind you)... Although I
think Jon has some reasons against doing that.
Comment 4 Ray Strode [halfline] 2008-03-10 11:28:43 EDT
So I talked to Jon about this today.

X now has a reliable way of detecting input events have happened (even when they
happen under a grab).

The IDLETIME sync counter.  We should just fix gnome-screensaver to use it and
then we won't hit this problem.
Comment 5 drago01 2008-03-10 14:56:12 EDT
(In reply to comment #4)
> So I talked to Jon about this today.
> 
> X now has a reliable way of detecting input events have happened (even when they
> happen under a grab).
> 
> The IDLETIME sync counter.  We should just fix gnome-screensaver to use it and
> then we won't hit this problem.

does this work with xserver < 1.5 too ? Or will the old method be still used for it?
Comment 6 Bug Zapper 2008-05-14 10:26:20 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. 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 '7'.

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 7'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 7 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. 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. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 7 Ray Strode [halfline] 2008-10-24 13:33:02 EDT
marking for rawhide, since it's still relevant
Comment 8 Bug Zapper 2008-11-25 20:59:38 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 9 Jeremy Katz 2009-03-04 19:30:39 EST
*** Bug 452433 has been marked as a duplicate of this bug. ***
Comment 10 Bug Zapper 2009-11-18 05:07:55 EST
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
Comment 11 Bug Zapper 2009-12-18 00:58:36 EST
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.
Comment 12 John Jackson 2011-02-02 12:36:51 EST
Hello.

I am experiencing what I believe to be a similar recurrance to this bug. I use gnome-rdp & tigervnc to remotely connect to other machines. When I restore back to windowed mode from full screen mode after the screensaver timeout, the screensaver kicks in. Moving the mouse while the screensaver is fading in has no effect. 

I originally reported this as a gnome-rdp bug (bug #666927), but after seeing it happen with both gnome-rdp and tigervnc, I did more searching and ran across this old bug. While minor, it is very annoying and looks weird when other people see this happen to me.

Note You need to log in before you can comment on or make changes to this bug.