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

Egbert Eich eich at suse.de
Tue Aug 8 01:44:03 PDT 2006


Keith Packard writes:
 > On Mon, 2006-07-31 at 11:37 +0200, Egbert Eich wrote:
 > 
 > > 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).
 > 
 > Yes, I think that's a good statement of the goals -- expose general
 > policy to the user agent and map those to device-specific states inside
 > the driver.
 > 
 > > All the mechanisms already exist. An application (screen saver) is free
 > > to disable the timers and do DPMS settings itself.
 > 
 > The only issue here is that when the application terminates, the DPMS
 > settings are left broken. It would be 'nicer' to provide a mechanism to
 > disable automatic DPMS state changes while leaving the timeouts around.

OK, you want to restore the default behavior (automatic DPMS state changes
controlled by server timeouts) when the app crashes? This seems to be 
reasonable.
Can we change the semantics to tell the Xserver to restore the previous
settings when the app gets terminated - and only allow one such app to
be present?
 > 
 > We've already got the ability to disable the screen saver without
 > adjusting the timings; is this sufficient here?

Possibly.
 > 
 > > 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. 
 > 
 > Yes, some kind of simple indication that the screen has been blanked
 > would probably be useful. Care will be needed to ensure applications
 > don't receive this while their output is still required though; we
 > already have visibility events which conflict with Composite in a
 > similar fashion.

Are you talking about visible output or framebuffer content?
Right now DPMS is just about visible output and shouldn't affect
composite.
This may change when we shut down the fb. I assume this situation
could be handled pretty much the same way we handle vt switches
right now.

Cheers,
	Egbert.



More information about the xorg mailing list