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

[Jay Cotton [TEMP]]

Jim:

The code is not free range yet.  Attached is the lib spec.  If you think
this would help your project, then I will push out the bits.

JC


Jim Gettys wrote:

>If I could find it, it might....  Where is the code/docs?
>                   Regards,
>                         - Jim
>
>
>On Tue, 2006-07-25 at 21:32 -0700, Jay Cotton wrote:
>  
>
>>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
>>>  
>>>      
>>>

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: FBPMLib.txt
URL: <http://lists.x.org/archives/xorg/attachments/20060726/9b129a2c/attachment.txt>