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

[Egbert Eich]

Keith Packard writes:
 > On Wed, 2006-07-26 at 12:48 -0700, Jay Cotton wrote:
 > 
 > > 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
 > 
 > I don't see any substantive difference between this extension and our
 > existing DPMS extension in terms of controlling the power levels in the
 > monitor. We should, instead, work to unify the core screen saver, DPMS,
 > FBPM and Screen Saver extensions into something usable by applications.
 > Adding another extension to this already horrible mess doesn't appear
 > helpful to me...
 > 
 > Some ideas:
 > 
 >  1) Existing external screen savers don't want the server to do anything
 > automatically. All power state transitions should be mediatable by an
 > external client.

'screen savers' are tools to prevent 'burn in' on CRT monitors when 
the same static image is displayed for too long. This is entirely 
different from power management. 
They work by changing the screen content often or just blank the 
display - which is by far less entertaining but better in terms 
of power consumption at least on CRTs.
Both the screen saving and energy saving concept have been combined
in some screen savers in which case the automatic energy saving (DPMS
and FBPS) should be isabled.
In the OLPC case however it is not even clear if people want an
external client to control things (it should not even be necessary
as there shouldn't be any visual artefacts just a slight delay in
screen content update after no update has happenend for a while).

 > 
 >  2) Power saving != screen blanking. Backlight levels dominate power use
 > by LCD screens, so a useful power saving mode is reduced backlight
 > level, which doesn't blank the screen. We should probably just expose
 > the backlight level through the X server and let the screen saver frob
 > that if it likes. Similarly, the OLPC color/mono switch could be made
 > visible as a power saving mode, but it may be that we should let that be
 > exposed through a separate extension as it is significantly different
 > than the normal power saving mechanisms.

Hm, when the backlight is off the screen is essentialy invisible
(except for the OLPC system in monochrome mode). If not driving the 
output will save you an additional amount of power you may want
to turn off more components on the chip.
Presently we have 3 DPMS power save state (which differ in the amount
of power savings and the time required to make the display operational
again). This is of course too coarse grained for backlight level 
control - but considering that backlights can be reenabled almost
instantaniously - we may want to turn it off entirely on any
power save states (I know that frequent backlight switching shortens
its lifetime unless the display uses a new LED backlight).
Do we want to create a common interface for backlight level control
thru the X protocol (and is the DPMS exension the right place for it?)

This seems to be something like other hardware dependent config
options and there has been the opinion that these don't need to
be configured thru the X protocol.

 > 
 >  3) I don't think the OLPC internal/external FB switching should be
 > visible to the user; it sounds like there is a 15-45ms lag when
 > switching between the two frame buffers, which is well under the usual

Is the OLPC switching between two framebuffers?
But regardless - point is, Jim mentioned that it
takes two frame times to wake up the chip according
to Jim. 

 > 100ms interactivity limit. As this can be entirely transparent to the
 > user, it should be.
 > 

I expect it will. Only the screen update will be delayed by 2 frames
when the content hasn't cahnged for a long time.
This seems to be sufficiently transparent to the user.

Cheers,
	Egbert.