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

[Jim Gettys]

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