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

[Jim Gettys]

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.
        
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....
        
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?
        
                                      - Jim
-- 
Jim Gettys
One Laptop Per Child