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

[Jay Cotton]

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

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

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