More advanced power savings (rev. the DPMS extension).
eich at suse.de
Sat Jul 29 04:32:33 PDT 2006
Jay, I've got a couple of questions here:
Jay Cotton writes:
> Frame Buffer Power Management (FBPM) Extension
> Library Specification
What is a framebuffer for you?
We use the term framebuffer for the memory that holds the
screen content including the non visible caches.
It seems like 'framebuffer' refers to everything that controls
video out on a graphics chipset - but does it also include
screen content update thru a. software b. 2d or 3d accel
engines? It may even be conceivable to disable the entire chip
and either save the framebuffer content somewhere else and/or
require apps to repaint on power up. The different state may
do different levels of hardware shutdown.
> 1. Overview
> This extension provides X Protocol control over the Frame
> Buffer Power Management (FBPM) characteristics of Excali-
> class video boards under control of the X Window System.
> 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
What is the benefit of decoupling framebuffer and screen power
management? The extension doesn't make any statement if the
screen content remains visible or not. Therefore apps that use
this extension cannot make any assumption here.
The initial coupling to DPMS even suggests that the screen content
is no longer visible on the output device when the 'framebuffer'
is powered down.
On the other hand the extension may be usable for Jim's purposes:
One could write an app that listens for screen updates using
DAMAGE. If the screen hasn't been updated for a while it would
force a transition to a power save state.
The only problem is that it will wake up when system has also
reached a DPMS power save state (due to lack of input activety
for a while) and the user hits a key - as in this situation a
DPMS state transition takes place which will synchronize the
FB and DPMS states again.
However if no power save state hasn't been entered yet (as none
of the timeouts have expired yet) the FB will remain in it's
powered down state.
While one may argue that an input event will most likely cause
something to be drawn to the screen and this the chip to wake up
it still seems to be awkward to combine the two,
> 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 level.
> FBPMModeOn Force frame buffer to on.
> FBPMModeStandby Force frame buffer to standby.
> FBPMModeSuspend Force frame buffer to suspend.
> FBPMModeOff Force frame buffer to off.
More information about the xorg