Proposed RandR per-CRTC DPMS requests

[Maarten Maathuis]

On Mon, Mar 24, 2008 at 4:50 PM, Keith Packard <keithp at keithp.com> wrote:
>
>
>  On Mon, 2008-03-24 at 13:32 +0100, Maarten Maathuis wrote:
>  > 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).
>
>  We change the X system by changing extensions; that's where we've got
>  API flexibility. For most applications, none of this stuff matters
>  though, only two kinds would ever need to use an extension:
>
>      1. The power manager -- needs to use SYNC to monitor idle time,
>         MIT-SCREEN-SAVER to disable automatic screen saving and hear
>         about other applications disabling automatic screen saving and
>         RANDR to select the appropriate DPMS level for each monitor.
>      2. Movie player applications which need to use MIT-SCREEN-SAVER to
>         disable the screen saver.
>
>
>  > Also, why would there be a dpms off counter per application, isn't a
>  > Bool enough?
>
>  one can imagine two separate parts of an application both wanting
>  control over the screen saver but sharing the same X connection. This is
>  already part of the MIT-SCREEN-SAVER applications.
>
>
>  > Maybe the "app controls dpms lock" is a bit overdone.

Your original proposal included a system in which an application could
acquire a lock, it would then recieve dpms events and decide what to
do with them, bypassing the built-in beheaviour. I couldn't imagine a
situation where this is needed.

>
>  I don't understand this part.
>
>
>  > 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.
>
>  Right, RandR already has events on all kinds of changes, so perhaps we
>  should add explicit DPMS state change events as well?

A generic callback that could be extended seems preferable.

>
>  --
>  keith.packard at intel.com
>