Proposed RandR per-CRTC DPMS requests

[Maarten Maathuis]

On Mon, Mar 24, 2008 at 6:41 AM, Keith Packard <keithp at keithp.com> wrote:
>
>  On Sun, 2008-03-23 at 21:06 -0700, Keith Packard wrote:
>  > 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.
>
>  Eric had a good critique, which pointed out some rather silly parts of
>  this plan.
>
>  Here's a simpler plan:
>
>      1. Use the IDLETIME Sync stuff to measure idle time.
>      2. Send events to the power manager when clients suspend the screen
>         saver through the MIT-SCREEN-SAVER extension
>      3. Add per-CRTC DPMS set/get requests
>      4. Make the screen saver app also use the MIT-SCREEN-SAVER suspend
>         request to suppress the built-in DPMS timers
>
>  Now the external power manager can monitor idle time and yet still know
>  when there are clients that do not want the screen saver to activate.
>  This is sufficient information for it to execute whatever policy it has
>  in mind.
>
>  This leaves one fairly simple question -- should we pull the
>  suspend/suspend-notify stuff into RandR and make them per-CRTC? That
>  would have the distinct advantage of allowing us to (eventually) get rid
>  of the MIT-SCREEN-SAVER extension, which appears otherwise entirely
>  worthless today.
>
>  (no, I don't have protocol proposed for this, it seems very simple to me
>  though).
>
>  --
>  keith.packard at intel.com
>
> _______________________________________________
>  xorg mailing list
>  xorg at lists.freedesktop.org
>  http://lists.freedesktop.org/mailman/listinfo/xorg
>

My preference would go for a system that would work independently of
any extensions, it would make the removal of obscure extensions
possible in the future (i'm not saying you shouldn't hook it up for
the time being).

Also, why would there be a dpms off counter per application, isn't a
Bool enough?

Maybe the "app controls dpms lock" is a bit overdone.

The most important thing seems the ability to register a callback, so
that a userspace application can recieve information about changes.
Consider making this a more general event, with information about any
randr related change.