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

[Egbert Eich]

Jay, I've got a couple of questions here:

Jay Cotton writes:
 > 
 >        Frame Buffer Power Management (FBPM) Extension
 > 
 >                    Library Specification
 > 

What is a framebuffer for you?
We use the term framebuffer for the memory that holds the 
screen content including the non visible caches.
It seems like 'framebuffer' refers to everything that controls
video out on a graphics chipset - but does it also include 
screen content update thru a. software b. 2d or 3d accel 
engines? It may even be conceivable to disable the entire chip
and either save the framebuffer content somewhere else and/or
require apps to repaint on power up. The different state may 
do different levels of hardware shutdown.

 > 1.  Overview
 > 
 > This extension provides X Protocol control  over  the  Frame
 > Buffer  Power  Management  (FBPM) characteristics of Excali-
 > berFp
 >  class video boards under control of the X Window System.
 > 
 > Traditionally, the X Window System  has  provided  for  both
 > blanking  and  non-blanking screen savers.  Timeouts associ-
 > ated with these built-in screen saver mechanisms are limited
 > to  idle  (dwell)  time, and a change timeout that specifies
 > the change interval for non-blanking screen savers.
 > 
 > The United States'  Environmental  Protection  Agency  (EPA)
 > Energy  Star program requires that monitors power down after
 > some idle time by default.  However in the case of Excaliber
 > and  follow  on products, power management has been extended
 > to include other parts  of  the  computer.   For  the  Frame
 > Buffer,  Excaliber  can  remove  power from the frame buffer
 > under program control.
 > 
 > There are four power levels specified by the Video Electron-
 > ics  Standards  Association  (VESA) Display Power Management
 > Signaling (DPMS) standard.  These are mapped onto the X FBPM
 > Extension like this:
 > 
 >   0            FBPMModeOn          In                    use
 >   1            FBPMModeStandby     In      standby     mode.
 >   2            FBPMModeSuspend     In     suspend      mode.
 >   3            FBPMModeOff         Shut     off,    awaiting
 > activity
 > 

What is the benefit of decoupling framebuffer and screen power
management? The extension doesn't make any statement if the 
screen content remains visible or not. Therefore apps that use
this extension cannot make any assumption here.
The initial coupling to DPMS even suggests that the screen content
is no longer visible on the output device when the 'framebuffer' 
is powered down.
On the other hand the extension may be usable for Jim's purposes:
One could write an app that listens for screen updates using 
DAMAGE. If the screen hasn't been updated for a while it would
force a transition to a power save state. 
The only problem is that it will wake up when system has also
reached a DPMS power save state (due to lack of input activety
for a while) and the user hits a key - as in this situation a
DPMS state transition takes place which will synchronize the
FB and DPMS states again.
However if no power save state hasn't been entered yet (as none
of the timeouts have expired yet) the FB will remain in it's
powered down state. 
While one may argue that an input event will most likely cause
something to be drawn to the screen and this the chip to wake up
it still seems to be awkward to combine the two,


 > 
 > The FBPMForceLevel function puts the frame buffer  into  the
 > requested  level, regardless of the DPMS power state.  Note,
 > the level will revert to track DPMS at the next  DPMS  power
 > state transition.
 > 
 > See table below for values of level.
 > 
 > FBPMModeOn     Force      frame      buffer      to      on.
 > FBPMModeStandby          Force   frame  buffer  to  standby.
 > FBPMModeSuspend          Force  frame  buffer  to   suspend.
 > FBPMModeOff    Force frame buffer to off.
 > 

Cheers,
	Egbert.