Proposed RandR per-CRTC DPMS requests

[Keith Packard]

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
power levels?

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.

                              ❧❧❧❧❧❧❧❧❧❧❧

DPMS Requests:

┌───
    RRCrtcDPMSGetInfo
        crtc: CRTC
      ▶
        capable: BOOL
        disabled: CARD32
        redirected: BOOL
        power_level: CARD16
        standby: CARD32
        suspend: CARD32
        off: CARD32
└───

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

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

┌───
    RRCrtcDPMSSetTimeouts
        crtc: CRTC
        standby: CARD32
        suspend: CARD32
        off: CARD32
└───

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

┌───
    RRCrtcDPMSSetPowerLevel
        crtc: CRTC
        power_level: CARD16
└───

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.

┌───
    RRCrtcDPMSDisable
        crtc: CRTC
└───

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.

┌───
    RRCrtcDPMSEnable
        crtc: CRTC
└───

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.

┌───
    RRCrtcDPMSRedirect
        crtc: CRTC
        enable: BOOL
└───


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.

                              ❧❧❧❧❧❧❧❧❧❧❧

DPMS Event:

┌───
    RRCrtcDPMSNotify
        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...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20080323/5f0dab8c/attachment.pgp>