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

[Egbert Eich]

Jay Cotton writes:
 > 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.

OK, this is the case for most of the chips we support.

 > >
 > > 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.

Right - at least in most cases (not im Jim's case). 
That's why I don't understand why both need to be decoupled.

 > > 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.

If you had a driver hook for DPMS (like our DDX does) you can do
something smart about the framebuffer when the screen is powered
down. 
You know that:
a. The screen isn't expected (and probably can't) display anything.
b. Until a CRT is back to full brightness it will take a few tenth
   of a second. You have enough time to turn the chip back on and
   restore your framebuffer content.

 > > 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 

So you can update the framebuffer without turning graphics components
back on?

 > 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.  

OK, how do you know that the user isn't looking at the screen - besides
using input activety to know that the user is active?

 > 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.

It would be very confisung to leave the screen on but not update
the content. I often times read thru documents, think about them
and don't do any input for a while which will let the screensaver
kick in.
This gives me a visual impression (although it's disturbing) that
the system has shut down the system because it thinks nobody is
looking at it.
Looking at a screen reading from one window while the other
window silently stops updating appears confusing to me.
I don't want that. I would like to know when the system makes
an assumption that is incorrect in a particular situation.

 > Also, in discussion with Jim, I think we will modify the code.  See 
 > latter email.

Right. Jim needs something different: his stuff needs to be output
triggered. He wants to wake up the chip whenever there is something
new to display.

Cheers,
	Egbert.