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

[Alex Deucher]

On 7/30/06, Egbert Eich <eich at suse.de> wrote:
> 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.

Just to give another real world example, here an eaxmple of the power
saving features and limiations available in the siliconmotion lynx
chips.  The specs are freely available on smi's website for those that
are intersted.

1.  PCI D0-D3 states

2.  functional block disabling - the various functional units (PLLs,
DAC, ZV port, drawing engine, etc.) can be explictily disabled or can
be controlled on the fly by enabling the chip's auto-standby mode.
the auto-standby timer is selectable from 0-64 minutes.  see below.

3. standby/sleep mode - standby: all functional blocks are disabled,
CRT and FP are blanked, clocks are reduced (selectable).  standby can
auto-controlled by the chip (see above).  sleep mode must be
programmed directly, but provides greater power savings.  Sleep modes
powers down all blocks and clocks and puts the vram into self refresh
mode.

This could probably be always enabled, however, it would be nice to be
able to select the timer, perhaps via the DPMS timer? sleep mode could
be enabled/disabled via DPMS off events.


4. Clock control (ReduceOn) - 2 levels
 - level 1 - reduce mclk by 25-50%
 - level2 - level 1, plus reduce core voltage (requires special hardware)
- limitations - not supported in dualhead mode, no gamma correction,
some limitations on 3D and video overlay.

Due to the limitations of "reduceOn" it would be nice to be able to
turn it on and off on the fly, so you could enable it or disable it
via ACPI events like the switch from AC to battery, etc.

5. auto shut-down of display memory screen refresh cycle -
automatically shuts down the memory screen refresh cycle, the
framebuffer write cycle, and the graphics and video FIFOs.  The
timeout for auto-shutdown is selectable from 8-64 frames. these are
automatically re-enabled if there is activity by the end of the next
vsync.  The flat panel remains active showing the content of the
screen.

This is only available on the FP controller so there are some fairly
major limiations including, only depth 8, 16 are supported, no
dualhead, FP only, no CRT, no video overlay.  Enabling this mode is
similar to a mode change, so it's not something you can really do on
the fly.  Once it's enabled though, it works smoothly.  It would be
nice to allow the user to turn this mode on for maximum power savings
when they know they will not be using a CRT or the video overlay, and
then disable it when  they need the other services.


I'm not sure how these mesh with other chip features.  I know ati
chips have clock gating and dynamic clock support, however, they are
not really documented.  savages also have dynamic gating and clocking
support.  these can probably be always enabled.  I'm not sure what
other features are available.

Alex

>
>  >
>  >  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.
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>