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

[Jim Gettys]

On Fri, 2006-07-28 at 11:28 -0700, Jay Cotton wrote:
> Jim Gettys wrote:
> > Enscript is my friend...
> >
> > I've taken a quick look at FBPM: it doesn't seem to fully define the
> > semantics of what happens to the screen independently of the frame
> > buffer (since I can drive the screen independently of the frame buffer).
> >   
> 
> At the time I did FBPM (1998) the intention was to power down the FB and 
> of course the CRT
> was going off since its connected to the FB.  These days we want to 
> extend this  to
> say something like:
> 
> -
>     FB is component 0
>     SCREEN is component 1
> 
>     DPMS controls component 1
>     FBPM controls component 0

At this point, we're up to 3 components:
   GPU
   video drivers (which eat significant power, if you have a low power
       panel as we do).
   screen. (ours can run autonomously, due to our DCON chip.)

Getting each of these back on line may have different potential
latencies, and therefore some desire for control over timeouts of when
they go into effect, as this affects the UI.

I can forsee possibly more: e.g. extra functional units on GPU's you
might want to power down when running on batteries.

Seems like we might want a bit more granularity.  Then again, that may
be going too far.

The question is: is a simplistic model like this sufficient, or are some
of the operating point concepts being developed in low power processors
more appropriate?

Can we get any insight from ATI or NVidia  folks on the mailing list
here on how much/what kind of controls we may have on power consumption
in coming graphics chips?

> 
> Many screens are dependent on the sync (HV) to determine the DPMS power 
> state, so in these
> cases when the FB is powered to off the screen will also be off.  In the 
> case where the screen
> has an independent sync source or does not need sync we have to control 
> it separately via DPMS.
> 
> The FBPM code needs to have independent (from DPMS) timers to allow for 
> asynchronous
> from DPMS time events actions.  These actions include:
> 
>     FBPM On
>     FBPM Off
>     FBPM Standby
>     FBPM Suspend
> 
> Timer resolution:
> 
>     I think we should allow users to set the timers in seconds, or 
> milliseconds, or time of day in 24 hour format.
> 
> Example:
> 
>     FBPMTimers(DPY, KIND, StandbyTimeValue, SuspendTimeValue, OffTimeValue)
> 
>     Where the time value is in milliseconds, or seconds, or time of day.
>     KIND will say what the format is supposed to be. I.e. milliseconds, 
> seconds....
> 

KISS: just milliseconds: it's good enough for this use, it is the common
X time format, and I can't imagine us needing timeouts more than the one
or two hundred days that 32 bits of milliseconds can represent.

> I don't think we should deal with mixed formats.
>    
> -
> 
> Does the above get closer to your needs. 
> > Also, I'd like to have the power control to be under timeouts in the X
> > server, so I'd like some way to set the timeouts when things go into
> > different states.  This is because the timings are potentially quite
> > short....
> >
> >                            Regards,
> >                             - Jim
> >
> >
> > On Wed, 2006-07-26 at 11:04 -0700, Jay Cotton [TEMP] wrote:
> >   
> 
-- 
Jim Gettys
One Laptop Per Child