Proposed RandR per-CRTC DPMS requests
keithp at keithp.com
Sun Mar 23 21:06:24 PDT 2008
On the list for RandR 1.3 are per-CRTC DPMS requests. I was looking at
gnome-power-manager today and noticed that it polls the X server (!)
every 10 seconds to check DPMS states. I figured it would be good to
write down at least a strawman proposal for how to fix that, along with
whatever other DPMS-ish stuff I could think of. Comments and criticism
are welcome as always.
Here's the overall plan:
Make DPMS timeouts and power levels per-CRTC. That allows each CRTC to
be powered down independently. Do we need per-CRTC timeouts? Or just the
We still need some kind of timeout as clients cannot otherwise tell when
the user is idle (some applications actually poll the mouse position,
which fails for people who don't move the mouse much). We could add a
separate 'idle time expired' mechanism if people think that would be
useful; I can think of lots of uses for that.
Events. Whenever the DPMS state changes, you can get an event sent to
you. Better than polling.
Redirection. A master 'power manager' can request that DPMS state
transitions be redirected to it. Instead of directly affecting the
associated CRTC, that client gets notification and can then decide what
to do. Only one client gets to do this (for each CRTC).
Disable counters. Just like the screen saver, when this counter is
non-zero, state transitions are inhibited. These counters are tracked
per-client and each clients contribution subtracted when they terminate.
Ok, so I've got a few open questions:
1) Separate idle timeout mechanism?
2) Specify CRTC None to indicate all crtcs on the system? Specify a
'DPMSable' which would be either a CRTC or a Window; if a Window,
then all CRTCS on the associated screen would be affected.
This request returns all of the DPMS information related to the specified
CRTC. 'capable' indicates whether this CRTC can be power managed with DPMS.
When 'disabled' is non-zero, DPMS timeouts will not change the DPMS state of
this CRTC (see RRCrtcDPMSDisable and RRCrtcDPMSEnable). When 'redirected' is
non-zero, DPMS state transitions will not be executed automatically, rather
after the specified timeout has passed, only the associated event will be
'power_level' indicates the current DPMS state of this CRTC. 'standby',
'suspend' and 'off' are the current DPMS idle timeouts which will trigger
transitions to the assocated state; if set to 0, the associated timeout is
This request sets the DPMS timeouts on the specified CRTC. If any timeouts
are now past, the appropriate DPMS state transition action will be taken
This sets the DPMS power level on the specified CRTC, generating suitable
RRCrtcDPMSNotify events. If another client has redirected DPMS transitions,
that client will receive a redirected event. If no client, or this client,
has redirected DPMS transitions, the DPMS transition will be effected and a
non-redirected DPMS event generated to all requesting clients.
This increments the 'disabled' count for the specified CRTC. When this
count is non-zero, DPMS timeouts will not affect the power_level of this
CRTC. These counts are tracked on a per-client basis, so if this client
exits, all counts will automatically be subtracted.
This decrements the 'disabled' count for the specified CRTC. If the
resulting 'disabled' count is now zero, the current DPMS timeouts will be
examined and the appropriate DPMS state will be entered.
This request changes DPMS state transistions for the specified CRTC. If
'enable' is True, no CRTC DPMS state changes occur; the redirecting client
receives appropriate RRCrtcDPMSNotifyEvents instead. Else, DPMS state
transitions revert to automatically transitioning the CRTC state and
generating RRCrtcDPMSNotify events to all interested clients. Only one
client may redirect DPMS events in this way; if another client has already
set the redirected value, an Access error results.
timestamp: TIMESTAMP time monitor was changed
window: WINDOW window requesting notification
crtc: CRTC CRTC which changed
redirected: BOOL actual or redirected
power_level: CARD16 entering power level
idle_time: CARD32 current idle time
This event is generated whenever DPMS transitions occur, whether as
a result of idle timeouts or through explicit client state
selections. 'power_level' indicates the DPMS state being
transitioned to, 'idle_time' is the current input idle time.
If 'redirected' is True, then the specified power_level transition
has not been made to the specified CRTC, rather the receiving client
has redirected DPMS transitions on this CRTC and is being notified
that a DPMS transition would have occurred to the specified
power_level. The redirecting client is free to use this information
however it likes; no actual transition will occur until the
redirecting client calls RRCrtcDPMSSetPowerLevel.
If 'redirected' is False, then the specified power_level transition
has been made to the specified CRTC.
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the xorg