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

[Jay Cotton]

Egbert Eich wrote:
> 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.
>   

I'm thinking of a board or welded onto the mobo type of device.  It 
generates the sync
and handles the screen memory.
>  > 1.  Overview
>  > 
>  > This extension provides X Protocol control  over  the  Frame
>  > Buffer  Power  Management  (FBPM) characteristics of Excali-
>  > berFp
>  >  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
>  > activity
>  > 
>
> 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.
>   

Thats is a confusing thing.  In fact if the frame buffer is powered 
down, the screen will be
undefined.  i.e. not working.
> 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.
>   
The original idea for FBPM was to add control for the screen in a 
somewhat independent
form.  So, we could control the frame buffer power without modifying DPMS.
> 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,
>   
On sparc systems the FB memory was mapped in such a way that the server 
was able to
write to 'what it thinks' is memory and not wake up the screen.  We wait 
for mouse/keyboard
to wake up the screen.  Also API is used to force the screen back on 
when an urgent need
is detected. 

The overall vision for power management has been that "If the user is 
not looking at the screen
there is no point is drawing on it".  This works almost all the time.  
Exceptions are, long render
times for OGL or maybe power plants or something.  But you can turn off 
FBPM if your at
a power plant.
>
>  > 
>  > 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.
>  > 
>
> Cheers,
> 	Egbert.
>   
Also, in discussion with Jim, I think we will modify the code.  See 
latter email.

JC