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

[Alex Deucher]

On 7/31/06, Egbert Eich <eich at suse.de> wrote:
> Keith Packard writes:
>  > > 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.
>  >
>  > These seem to map to existing DPMS levels cleanly; is there any need to
>  > expose them separately?
>
> I don't think so. Sleep mode could be mapped to the 'off' state of
> DPMS.
> I presently see no need to add other controls for power management.

I agree.  I think these map pretty well to DPMS states.

> A lot of this is driver specific and should be left under the control
> of the driver. The driver should apply best practices (which may be
> overridden by explicite config options - some of which may be dynamic
> as it may be desireable to alter the driver policy at runtime other
> can even be static as they deal more with the ideosyncrasies of a
> specifc system than with user preferences).
> Exposing too much of the chip to a client app requires
> chipset specific clients to deal with power management.
> This begs the question why not dealing with setting the power
> states in the driver in the first place - and possibly just
> expose controls for policy).

I think it make sense to make power management driver specific.  There
may be some common features, but if we are careful and keep the
attributes similar, there shouldn't be a problem (works well for
things like brightness and contrast in Xv).  user apps could then
query teh server the for available options and create there own
inferface (check box, slider, etc.) for the option type (int, float,
bool).  you could even provide a "pretty" name (and even description)
to expose to userspace for the option.

>
>  >
>  > > 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.
>  >
>  > We may leave the existing DPMS timers around, but the 'normal' mode of
>  > operation would be to leave the DPMS state transitions entirely under
>  > the control of the external screen saver and power manager daemons. The
>  > policy for when to entertain the user with a random screen saver image
>  > and when to save power cannot easily be encapsulated in a random set of
>  > timeouts, so we should just give up and let the client figure out what
>  > it wants. All the X server should do is expose the appropriate
>  > mechanisms to notify clients about idle time (using events with
>  > client-specified timeouts); that seems easy to do with the Sync
>  > extension. DPMS state transitions can be handled by the existing DPMS
>  > extension, although I'd like to allow clients to 'take over' the timeout
>  > policy without having to reset the values; when said clients terminate,
>  > the built-in policy would take over.
>
> All the mechanisms already exist. An application (screen saver) is free
> to disable the timers and do DPMS settings itself.
> Screen savers that don't do it probably don't care about power management.
> However when no DPMS aware client app is around why shouldn't the Xserver
> take care of the DPMS powerstates itself?
> On the other hand it may be worthwile to add DPMS events to notify
> other clients of DPMS mode changes.
>  >
>  > > 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.
>  >
>  > This looks a lot like the cpufreq stuff; right now, the 'best' policy
>  > we've found for that is to build sensible default behaviour into the
>  > kernel (ondemand), while also exposing it to user mode. I'd like to see
>  > if there isn't a way to eliminate this from the client's view and create
>  > a built-in power management policy for each driver. If we find common
>  > policies, we can look at merging multiple driver mechanisms together.
>  >
>
> Yep.
>

Agreed.

> Cheers,
>         Egbert.
>