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

[Jay Cotton]

Hi Jim:

I wonder if this is a good use for FBPM (frame buffer power management)?

This extension allows you to get your power management done without changing
DPMS.

JC

Jim Gettys wrote:
> 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
>