Proposed RandR per-CRTC DPMS requests
Maarten Maathuis
madman2003 at gmail.com
Mon Mar 24 11:14:02 PDT 2008
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
>
More information about the xorg
mailing list