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