Proposed RandR per-CRTC DPMS requests

[Keith Packard]

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.

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?

-- 
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/20080324/283a4c57/attachment.pgp>