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

Keith Packard keithp at
Mon Jul 31 09:11:23 PDT 2006

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.

We've already got the ability to disable the screen saver without
adjusting the timings; is this sufficient here?

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

keith.packard at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the xorg mailing list