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

[Egbert Eich]

Jim Gettys writes:
 > Problem statement
 > =================
 >         
 > We have a display that is new: it is possible the chip driving
 > the panel to take over panel update from the processor.  We can save
 > significant power if, while displaying an idle screen, we power down the
 > processor's video driver logic, and even more power if we power down the
 > graphics processor itself.  To resynchronize the display will take a
 > couple frame times, so for highly interactive scenes, this behavior is
 > not desirable; but when the screen is idle for any significant length of
 > time, it is.
 >         
 > Hard-wiring these values into the X server seems like a poor plan; the
 > latencies of powering up a GPU will vary (it can take time to stabilize
 > clocks and another power domain on graphics chips), and it will likely
 > usually take of order 2 frame times (and hardware interrupt driver
 > support) to transfer control of screen refresh back to the processor,
 > and such transitions may vary, depending on the hardware.
 >         
 > I expect it is likely such displays and power controllable GPU's will
 > become much more common in the future.
 > 
 > Suggested course of action
 > ==========================
 >         
 > It appears that making a minor revision to the DPMS extension may be
 > most appropriate, adding a request or two to set timeouts for video and
 > GPU powerdown when the screen is idle.
 >         
 > Plan 1
 > ------
 > The first approach (plan 1) I'll describe would be to actually *use* the
 > defined VESA Power Level States for the first time in a useful fashiond,
 > mapping these in the following semantic ways that may make sense.
 >         
 >         val     Name            Definition according to VESA            
 >         ---
 >         0       DMSModeOn       In use              
 >         1       DPMSModeStandby Blanked, low power  
 >         2       DPMSModeSuspend Blanked, lower power
 >         3       DPMSModeOff     Shut off, awaiting activity
 >         
 >         val     Name            New Definition          
 >         ---
 >         0       DMSModeOn       In use              
 >         1       DPMSModeStandby Screen on, processor video off 
 >         2       DPMSModeSuspend Screen on, processor video off, GPU off
 >         3       DPMSModeOff     Shut off, awaiting activity
 >         
 >         
 > Plan 2
 > ------
 > A second approach (plan 2) is to add a few states, and insert them
 > between state 0 and state 1, if they are defined to be non-zero, and
 > have the extension do the usual state transitions from low to high.

Generally using DPMS to not only power down the display but also 
circuits on the chipset that control the output makes perfect sense.

But from what I'm reading here I don't know if DPMS is really the
extension you are looking for:
DPMS is controlled by user input not by output activety.
Are you looking for something that:
a: allows the application to turn on power save when it knows
   it will not change screen content?
b: Something to set an automatic timeout behavior on a per app base?
c: Just be able to modify the timeout?

For a the dpms extension (at least plan 1) doesn't seem to be the
way to go: if the app is run on a 'normal' machine it would constantly
turn off the display as the 'screen content stays visible' is not
the dormal behavior of DPMS and must not be assumed.
I'm not sure if piggy backing on DPMS is really the right thing to
go here.
For b and c you would need a detection for screen content change.
DAMAGE may help here. However b is entirely different from the
scope of DPMS so you may want to come up with a different extension
for your purpose.
c can be done thru one of the existing or to be designed driver conf
mechanisms. Doesn't seem to require an extension.

 >         
 > Previous insane design
 > ======================
 >         
 > Unfortunately, for reasons that are completely lost in the mists of
 > time, the timeouts in the DPMS extension are specified in seconds as
 > CARD16's, rather than the more natural X Timestamp CARD32 units of 1
 > millisecond, and to top it off, these CARD16 choices even show through
 > the DPMS library.  Ugh....  As if saving 16 bits on setting DPMS values
 > was going to be a performance win or something....

DPMS is not ment for short timeout periods as it's input driven.


 >         
 > Due to this insane design, no matter what, I'll have to add a few
 > requests.  Sigh.
 >         
 > But the first question I'll make to the list is, do you like plan 1, or
 > plan 2, or Plan 9 from Outer Space ;-)
 >         
 > If you like plan 2, then the question is how many additional states do
 > we really need, anyway?  How should we define them?
 >         

Your case is rather special (at least for today's hardware).
I'm not convinced that adding this to DPMS is the way to go.
Depending on what you need (see above) you may want to create
a new extension. Apps can check if it is there and don't get
confused by the presence of DPMS but the absense of these 
special features.

Cheers,
	Egbert.