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 activity. 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: https://bugs.freedesktop.org/show_bug.cgi?id=1419 http://bugzilla.gnome.org/show_bug.cgi?id=346806 http://bugzilla.gnome.org/show_bug.cgi?id=337203 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 multiple displays. 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. https://bugs.freedesktop.org/show_bug.cgi?id=1419
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 activity. 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 [1] would be ideal. From what I have read, only v1.0 (single client) has been implemented so far. Does this seem reasonable? [1] http://people.freedesktop.org/~ajax/xevie/xevie-spec.1.1.html
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).