More advanced power savings (rev. the DPMS extension).

[Egbert Eich]

Keith Packard writes:
 > > 3. standby/sleep mode - standby: all functional blocks are disabled,
 > > CRT and FP are blanked, clocks are reduced (selectable).  standby can
 > > auto-controlled by the chip (see above).  sleep mode must be
 > > programmed directly, but provides greater power savings.  Sleep modes
 > > powers down all blocks and clocks and puts the vram into self refresh
 > > mode.
 > 
 > These seem to map to existing DPMS levels cleanly; is there any need to
 > expose them separately?

I don't think so. Sleep mode could be mapped to the 'off' state of
DPMS.
I presently see no need to add other controls for power management.
A lot of this is driver specific and should be left under the control
of the driver. The driver should apply best practices (which may be
overridden by explicite config options - some of which may be dynamic
as it may be desireable to alter the driver policy at runtime other
can even be static as they deal more with the ideosyncrasies of a 
specifc system than with user preferences).
Exposing too much of the chip to a client app requires
chipset specific clients to deal with power management. 
This begs the question why not dealing with setting the power
states in the driver in the first place - and possibly just
expose controls for policy).

 > 
 > > This could probably be always enabled, however, it would be nice to be
 > > able to select the timer, perhaps via the DPMS timer? sleep mode could
 > > be enabled/disabled via DPMS off events.
 > 
 > We may leave the existing DPMS timers around, but the 'normal' mode of
 > operation would be to leave the DPMS state transitions entirely under
 > the control of the external screen saver and power manager daemons. The
 > policy for when to entertain the user with a random screen saver image
 > and when to save power cannot easily be encapsulated in a random set of
 > timeouts, so we should just give up and let the client figure out what
 > it wants. All the X server should do is expose the appropriate
 > mechanisms to notify clients about idle time (using events with
 > client-specified timeouts); that seems easy to do with the Sync
 > extension. DPMS state transitions can be handled by the existing DPMS
 > extension, although I'd like to allow clients to 'take over' the timeout
 > policy without having to reset the values; when said clients terminate,
 > the built-in policy would take over.

All the mechanisms already exist. An application (screen saver) is free
to disable the timers and do DPMS settings itself.
Screen savers that don't do it probably don't care about power management.
However when no DPMS aware client app is around why shouldn't the Xserver
take care of the DPMS powerstates itself?
On the other hand it may be worthwile to add DPMS events to notify
other clients of DPMS mode changes. 
 > 
 > > 4. Clock control (ReduceOn) - 2 levels
 > >  - level 1 - reduce mclk by 25-50%
 > >  - level2 - level 1, plus reduce core voltage (requires special hardware)
 > > - limitations - not supported in dualhead mode, no gamma correction,
 > > some limitations on 3D and video overlay.
 > > 
 > > Due to the limitations of "reduceOn" it would be nice to be able to
 > > turn it on and off on the fly, so you could enable it or disable it
 > > via ACPI events like the switch from AC to battery, etc.
 > 
 > This looks a lot like the cpufreq stuff; right now, the 'best' policy
 > we've found for that is to build sensible default behaviour into the
 > kernel (ondemand), while also exposing it to user mode. I'd like to see
 > if there isn't a way to eliminate this from the client's view and create
 > a built-in power management policy for each driver. If we find common
 > policies, we can look at merging multiple driver mechanisms together.
 > 

Yep.

Cheers,
	Egbert.