More advanced power savings (rev. the DPMS extension).
Jay.Cotton at Sun.COM
Fri Jul 28 11:28:33 PDT 2006
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
from DPMS time events actions. These actions include:
I think we should allow users to set the timers in seconds, or
milliseconds, or time of day in 24 hour format.
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,
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
> - Jim
> On Wed, 2006-07-26 at 11:04 -0700, Jay Cotton [TEMP] wrote:
More information about the xorg