Okay, after having F11 g-p-m blank the screen on me whilst watching some short videos in totem yesterday, I got really angry. It seems lots of other people feel the same way.
I’ve audited all the IDLETIME code in gnome-power-manager multiple times, and when I’ve run it in a console and watched the output, it all seems to work 100% okay for days on end, and then fails when you’re actually trying to do something. And then I had an epiphany: It only seems to fall over gnome-session is involved with handling inhibits.
So, this works:
GPMIDLEDEBUG=1 ./gnome-power-manager…wait 10 seconds…
IDLETIME fires the idle alarm expired (and g-p-m dims the screen) and the reset alarm is setup
…move the mouse…IDLETIME fires the reset alarm expired
Then I issue an inhibit request to org.gnome.SessionManager with parameters (‘test-program’,0,’testing’,8) using d-feet and get back a cookie like normal. Session becomes inhibited.
…wait 10 seconds…IDLETIME fires the idle alarm expired (but g-p-m doesn’t dim the screen, as the session is inhibited from totem) and the reset alarm is setup
…move the mouse…NOTHING. No event from X.
…close d-feet…The inhibit gets auto-revoked, session becomes non-inhibited, and g-p-m assumes that x has been idle for a long time, and also the session is not inhibited, and so switches off the screen. You can see this when using GPMIDLEDEBUG as the second icon is a box, not a computer icon.
Now g-p-m is confused, and has to be restarted before it will reset the new idletime counter. You can’t reproduce with the original idlecounter-demo program when using XNextEvent, but you can as soon as you hook into gdk with gdk_window_add_filter. It really looks like something is doing GDK_FILTER_REMOVE on the reset alarm at some point. There’s a test program here which you can see the bug without gnome-power-manager running, just to prove it’s not a silly bug or race in gnome-power-manager. It could also be an X bug, as the XSync stuff isn’t that widely used, although all gnome-session is doing is XSyncDestroyAlarm’ing an alarm, which shouldn’t affect gnome-power-manager’s alarms at all.
After looking in the forums, this problem looks like it’s triggered lots, and by many different users. I would appreciate any help here as I’m well and truly stuck. Thanks.
Richard.
p.s. if anyone knows how to debug gnome-session to see the debug output, I would be very grateful. Any attempts at replacing gnome-session process in my session lead me to a forced logout.
Just writing to say, I have the same problem since installing Fedora 11. ;)
I’d thought I was going crazy! It’s a really difficult bug to describe, I’m glad I happened upon your blog (although if you have a bug report for following this issue, that’d be brilliant!).
I don’t know of a way to replace the gnome-session process, but if you’ve got an easily reproducible test, and you think the problem’s in gnome-session, have you considered trying a git (or subversion if the bug’s really old) bisect to see what might’ve caused it? It’s a long shot, but you can quickly see whether it’s likely to succeed or not by rolling back gnome-session. If 2.24 doesn’t feature the problem, then it’s definitely worth bisecting…
Just for the record for anyone reading, the Fedora bug report for this is https://bugzilla.redhat.com/show_bug.cgi?id=501601 .
sorry, I cannot offer any gnome-session debugging experience whatsoever here. hopefully someone can fill the void. Actually, I just wanted to say that after trying out so much stuff out there in the wild of forums and the like, its great you took so much effort to find the most comprehensive answer to the root of the problem. I suffered from this issue greatly since upgrading to F11 (actually it just happened while writing – as in typing- this post).
I’m not sure if it’s related, but apart from the screen blanking when I’m watching a movie, neither time-triggered blank nor suspend seem to work for me. I reported this in red hat bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=514295
Start an X session with no desktop environment, just a window manager; or alternatively just an xterm.
In your xterm run gnome-session or gdb gnome-session or what have you.
now, that i thought some more about it, its kind of weird i had never experienced these blank screens (or attempts for it) on my machine at work – running in a virtualbox container – though i am using F11 this way since close to one week after release. Maybe vista (cough) or virtualbox do someting to prevent this. ACPI’s, etc. working fine. Some clues what to check for are indeed welcome …
You should be able to login to a failsafe X session and then start g-s however you want.
Richard,
I turned off “Activate screensaver when computer is idle” in
System-Preferences-Screensaver.
This fixed the blanking problem.
This is now fixed — see http://blogs.gnome.org/hughsie/2009/08/14/blanking-in-gnome-power-manager-fixed/ for details.