Description of problem:
gnome-screensaver is one of the applications that keep the X server busy all the
time, just by polling for the current mouse position once per second. g-ss
appears to do this in order to find out if the mouse has moved to detect user
This is a bit silly; X has an entire API to support screen savers with this kind
of thing, there is no need to poll for this kind of thing at all.
The result of this is that the processor and chipsets aren't sleeping as much as
they should, and thus battery life time is wasted for no good reason.
If you are interested in some of the reasons:
Basically it boils down to the fact that the API is um interesting and less than
ideal. And it may not actually work correctly (or the way we want it to) with
XEvie looks near perfect except that it presently only supports one client at a
time and this is usually one of the a11y tools.
So tell me what you want and I'll stick it into X.org 7.2
jwz (of xscreensaver) has been begging for X11R5's XIDLE extension to be brought
back for years now.
XIDLE would not help, because it's a polling design.
We can add events to XIDLE. We have the power.
Also note that using the standard screensaver extension would allow
gnome-screensaver to detect activity using means other than mouse movement; for
example, all the random movie players which can disable screensavers while
playing will also disable gnome-screensaver, and new types of input devices that
gnome-screensaver doesn't know about can still register activity as long as X
knows about them.
gnome-screensaver gives the user a 10 second warning before the screen is
blanked/locked due to idleness. During this time the screens slowly fade to
black. Any activity should immediately cancel the fade-out and reset the
screensaver idle detection. X input is only one of the possible sources of
In this case and in a few others what is important is not an event after an idle
period but rather an event when significant input occurs. For this both xidle
and the screen saver extension don't seem to be able to help us.
It seems to me, from the spec, that XEvIE v1.1  would be ideal. From what I
have read, only v1.0 (single client) has been implemented so far.
Does this seem reasonable?
so you probably want a non-longer-idle event to follow if the user does anything,
after the initial idle event...
Matthias: For the x server to generate events on idle (or not) then there must
be a policy defined for what idle is. If policy resides in the x server then we
may need to make it use GConf and make sure that no policy can be set from
clients via normal API.
With things as they are now, I think we should be able to get rid of most of the
polling (or limit the polling to the "warning" interval) by using the
screensaver extension at the time of expected activation only to get the time
since last activity.
gconf in the X server ? thats a nonstarter...
whatever exension lets you get idle events from the server needs to provide
an api to set policy.
(In reply to comment #10)
> gconf in the X server ? thats a nonstarter...
I realize that gconf won't make it into the x server. That's one reason why I'm
not sure policy belongs there either.
> whatever exension lets you get idle events from the server needs to provide
> an api to set policy.
If this policy is per client then I agree with you.
So what does gnome-screensaver do at this moment? I just upgraded to the latest
F8 kernel / packages and gnome-screensaver (g-s) and something is making my
mythtv glitch the video every 60 secs or so. I finally tracked it down to g-s
eating a big chunk of CPU at the exact moment of the glitch. WTF is g-s doing
that requires such horsepower at such a high priority? I killed g-s and now
there is no glitch.
Can g-s really nice itself, I'm sure what it needs to do is non-time-sensitive.
The old version (or something else related to it) did not do this.
I may make a new bug for this.
This polling has been fixed upstream quite a while ago. There are a few bugs in
upstream bugzilla that are related (for using XSS, xsync etc).