More information from the author of GPM (Richard Hughes), this was sent to the gnome-power-manager developer mailing list:
Okay, after having F11 g-p-m blank the screen on me (not using
nouveau, that's a separate issue) whilst watching some short videos in
totem yesterday, I got really angry.
I've audited all the IDLETIME code in gnome-power-manager, and when
I've run it in a console and watched the output, it all seems to work
100% okay. It only seems to fall over gnome-session is involved with
handling inhibits.
So, we have working:
GPMIDLEDEBUG=1 gnome-power-manager
...wait 10 seconds...
IDLETIME fires the idle alarm expired (and g-p-m dims the screen)
...move the mouse...
IDLETIME fires the reset alarm expired
then I issue an inhibit request to org.gnome.SessionManager with
parameters ('moo',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)
...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 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.
As an aside, it appears totem is inhibiting using gnome-screensaver as
a proxy, although I don't this this is the problem as it also can be
done using d-feet.
After looking in the forums, this problem looks like it's triggered
lots, and by many different users. I would appreciate any help here.
More information from the author of GPM (Richard Hughes), this was sent to the gnome-power-manager developer mailing list:
Okay, after having F11 g-p-m blank the screen on me (not using
nouveau, that's a separate issue) whilst watching some short videos in
totem yesterday, I got really angry.
I've audited all the IDLETIME code in gnome-power- manager, and when
I've run it in a console and watched the output, it all seems to work
100% okay. It only seems to fall over gnome-session is involved with
handling inhibits.
So, we have working:
GPMIDLEDEBUG=1 gnome-power-manager
...wait 10 seconds...
IDLETIME fires the idle alarm expired (and g-p-m dims the screen)
...move the mouse...
IDLETIME fires the reset alarm expired
then I issue an inhibit request to org.gnome. SessionManager with 0,'testing' ,8) using d-feet and get back a cookie
parameters ('moo',
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)
...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 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 add_filter. It really looks like
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_
something is doing GDK_FILTER_REMOVE on the reset alarm at some point.
As an aside, it appears totem is inhibiting using gnome-screensaver as
a proxy, although I don't this this is the problem as it also can be
done using d-feet.
After looking in the forums, this problem looks like it's triggered
lots, and by many different users. I would appreciate any help here.
Richard.