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

Jim Gettys jg at laptop.org
Fri Jul 28 10:37:23 PDT 2006


Enscript is my friend...

I've taken a quick look at FBPM: it doesn't seem to fully define the
semantics of what happens to the screen independently of the frame
buffer (since I can drive the screen independently of the frame buffer).

Also, I'd like to have the power control to be under timeouts in the X
server, so I'd like some way to set the timeouts when things go into
different states.  This is because the timings are potentially quite
short....

                           Regards,
                            - Jim


On Wed, 2006-07-26 at 11:04 -0700, Jay Cotton [TEMP] wrote:
> 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
> >>>  
> >>>      
> >>>
> 
> plain text document attachment (FBPMLib.txt)
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>        FFFFrrrraaaammmmeeee BBBBuuuuffffffffeeeerrrr PPPPoooowwwweeeerrrr MMMMaaaannnnaaaaggggeeeemmmmeeeennnntttt ((((FFFFBBBBPPPPMMMM)))) EEEExxxxtttteeeennnnssssiiiioooonnnn
> 
>                    LLLLiiiibbbbrrrraaaarrrryyyy SSSSppppeeeecccciiiiffffiiiiccccaaaattttiiiioooonnnn
> 
> 
> 
>                         Version 1.2
>                   XServer upgrade project
>                  X Version 11, Release 6.4
> 
> 
> 
> 
> 
> 
>                          Jay Cotton
>                    _j_a_y._c_o_t_t_o_n at _E_n_g._S_U_N._C_o_m
> 9                     Sun Microsystems
> 9                        23 July 1999
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Copyright 8c9 Sun Microsystems, 1999
> 
> Permission to use, copy, modify, distribute, and  sell  this
> documentation for any purpose is hereby granted without fee,
> provided that the above copyright notice and this permission
> notice  appear  in  all  copies.  Sun  Microsystems makes no
> representations about the suitability for any purpose of the
> information  in  this  document.  This documentation is pro-
> vided ``as is'' without express or implied warranty.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _1.  _O_v_e_r_v_i_e_w
> 
> This extension provides X Protocol control  over  the  Frame
> Buffer  Power  Management  (FBPM) characteristics of _E_x_c_a_l_i_-
> _b_e_r_F_p
>  _c_l_a_s_s _v_i_d_e_o _b_o_a_r_d_s _u_n_d_e_r _c_o_n_t_r_o_l _o_f _t_h_e _X _W_i_n_d_o_w _S_y_s_t_e_m.
> 
> Traditionally, the X Window System  has  provided  for  both
> blanking  and  non-blanking screen savers.  Timeouts associ-
> ated with these built-in screen saver mechanisms are limited
> to  idle  (dwell)  time, and a change timeout that specifies
> the change interval for non-blanking screen savers.
> 
> The United States'  Environmental  Protection  Agency  (EPA)
> Energy  Star program requires that monitors power down after
> some idle time by default.  However in the case of Excaliber
> and  follow  on products, power management has been extended
> to include other parts  of  the  computer.   For  the  Frame
> Buffer,  Excaliber  can  remove  power from the frame buffer
> under program control.
> 
> There are four power levels specified by the Video Electron-
> ics  Standards  Association  (VESA) Display Power Management
> Signaling (DPMS) standard.  These are mapped onto the X FBPM
> Extension like this:
> 
>   0            FBPMModeOn          In                    use
>   1            FBPMModeStandby     In      standby     mode.
>   2            FBPMModeSuspend     In     suspend      mode.
>   3            FBPMModeOff         Shut     off,    awaiting
> activity
> 
> 
> _2.  _F_B_P_M _F_u_n_c_t_i_o_n_s
> 
> 
> 
> Bool FBPMQueryExtension (_d_i_s_p_l_a_y, _e_v_e_n_t__b_a_s_e, _e_r_r_o_r__b_a_s_e)
> 
>          Display *_d_i_s_p_l_a_y;
>          int *_e_v_e_n_t__b_a_s_e, *_e_r_r_o_r__b_a_s_e;
> 
> _d_i_s_p_l_a_y Specifies the connection to the X server.
> _e_v_e_n_t__b_a_s_e      Specifies  the  return  location   for   the
> assigned base event
> _e_r_r_o_r__b_a_s_e      Specifies  the  return  location   for   the
> assigned base error
> 
> 
> The FBPMQueryExtension function  queries  the  X  server  to
> determine  the  availability  of the FBPM Extension.  If the
> _________________________
> 1. _X _W_i_n_d_o_w _S_y_s_t_e_m is a trademark of X Consortium, Inc.
> 
> 
> 
> 
>                              1111
> 
> 
> 
> 
> 
> FFFFrrrraaaammmmeeee BBBBuuuuffffffffeeeerrrr PPPPoooowwwweeeerrrr MMMMaaaannnnaaaaggggeeeemmmmeeeennnntttt ((((FFFFBBBBPPPPMMMM)))) EEEExxxxtttteeeennnnssssiiiioooonnnn
> 
> 
> extension is  available,  the  return  value  is  TRUE,  and
> _e_v_e_n_t__b_a_s_e  and  _e_r_r_o_r__b_a_s_e are set to the base event number
> and base error number for the extension, respectively.  Oth-
> erwise,  the  return  value  is  FALSE,  and  the  values of
> _e_v_e_n_t__b_a_s_e and _e_r_r_o_r__b_a_s_e are undefined.
> 
> 
> 
> 
> Status FBPMGetVersion(_d_i_s_p_l_a_y, _m_a_j_o_r__v_e_r_s_i_o_n, _m_i_n_o_r__v_e_r_s_i_o_n)
> 
>          Display *_d_i_s_p_l_a_y;
>          int     *_m_a_j_o_r__v_e_r_s_i_o_n, *_m_i_n_o_r__v_e_r_s_i_o_n;
> 
> _d_i_s_p_l_a_y         Specifies the connection to the X server.
> _m_a_j_o_r__v_e_r_s_i_o_n   Specifies the return location for the exten-
> sion major version.
> _m_i_n_o_r__v_e_r_s_i_o_n   Specifies the return location for the exten-
> sion minor version.
> 
> 
> The FBPMGetVersion function returns the version of the  FBPM
> extension  implemented  by  the  X  server.   The version is
> returned in _m_a_j_o_r__v_e_r_s_i_o_n and _m_i_n_o_r__v_e_r_s_i_o_n.  The major ver-
> sion  and  minor  version for this specification are '1' and
> '1', respectively.  The major version  will  be  incremented
> for  protocol  incompatible  changes,  and the minor version
> will be incremented for small, upwardly compatible changes.
> 
> 
> 
> 
> Bool FBPMCapable(_d_i_s_p_l_a_y)
> 
>          Display *_d_i_s_p_l_a_y;
> 
> _d_i_s_p_l_a_y Specifies the connection to the X server.
> 
> 
> The FBPMCapable function returns the FBPM capability of  the
> X  server, either TRUE (capable of FBPM) or FALSE (incapable
> of FBPM).  The capability of an X server  is  implementation
> defined.   For example, if a multi-headed  X server is capa-
> ble of FBPM on one head, and incapable on another, the truth
> value  of this function is defined by the X server implemen-
> tation.
> 
> 
> 
> 
> 
> Bool FBPMEnable(_d_i_s_p_l_a_y)
> 
>          Display *_d_i_s_p_l_a_y;
> 
> 
> 
>                              2222
> 
> 
> 
> 
> 
> FFFFrrrraaaammmmeeee BBBBuuuuffffffffeeeerrrr PPPPoooowwwweeeerrrr MMMMaaaannnnaaaaggggeeeemmmmeeeennnntttt ((((FFFFBBBBPPPPMMMM)))) EEEExxxxtttteeeennnnssssiiiioooonnnn
> 
> 
> _d_i_s_p_l_a_y Specifies the connection to the X server.
> 
> 
> The  FBPMEnable  function  enables  FBPM  on  the  specified
> display. When enabled, power off assertion occures when DPMS
> transitions from Suspend->Off.  Power up occures  when  DPMS
> Transitions to On from any state.
> 
> 
> 
> 
> Bool FBPMForceLevel(_d_i_s_p_l_a_y,_l_e_v_e_l)
> 
>          Display *_d_i_s_p_l_a_y;
>          int  _l_e_v_e_l;
> 
> _d_i_s_p_l_a_y Specifies  the   connection   to   the   X   server.
> _l_e_v_e_l   Power level to force the frame buffer into.
> 
> The FBPMForceLevel function puts the frame buffer  into  the
> requested  level, regardless of the DPMS power state.  Note,
> the level will revert to track DPMS at the next  DPMS  power
> state transition.
> 
> See table below for values of _l_e_v_e_l.
> 
> FBPMModeOn     Force      frame      buffer      to      on.
> FBPMModeStandby          Force   frame  buffer  to  standby.
> FBPMModeSuspend          Force  frame  buffer  to   suspend.
> FBPMModeOff    Force frame buffer to off.
> 
> 
> 
> 
> 
> 
> Status FBPMDisable(_d_i_s_p_l_a_y)
> 
>          Display *_d_i_s_p_l_a_y;
> 
> _d_i_s_p_l_a_y Specifies the connection to the X server.
> 
> 
> The FBPMDisable function  disables  FBPM  on  the  specified
> display.  When disabled, no power states are asserted on the
> frame buffer.
> 
> 
> 
> 
> 
> Status FBPMInfo(_d_i_s_p_l_a_y, _s_t_a_t_e)
> 
>          Display *_d_i_s_p_l_a_y;
> 
> 
> 
>                              3333
> 
> 
> 
> 
> 
> FFFFrrrraaaammmmeeee BBBBuuuuffffffffeeeerrrr PPPPoooowwwweeeerrrr MMMMaaaannnnaaaaggggeeeemmmmeeeennnntttt ((((FFFFBBBBPPPPMMMM)))) EEEExxxxtttteeeennnnssssiiiioooonnnn
> 
> 
>          BOOL *_s_t_a_t_e;
> 
> _d_i_s_p_l_a_y         Specifies the connection to the X server.
> _s_t_a_t_e                   Specifies the current FBPM state
> 
> 
> The FBPMInfo function returns information about the  current
> FBPM state.  The _s_t_a_t_e return parameter indicates whether or
> not FBPM is enabled (TRUE) or disabled (FALSE).
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                              4444
> 
> 
-- 
Jim Gettys
One Laptop Per Child





More information about the xorg mailing list