More advanced power savings (rev. the DPMS extension).

Alex Deucher alexdeucher at gmail.com
Wed Jul 26 15:21:17 PDT 2006


On 7/26/06, Alex Deucher <alexdeucher at gmail.com> wrote:
> On 7/26/06, Egbert Eich <eich at suse.de> wrote:
> > Alex Deucher writes:
> >  > >
> >  > > Your case is rather special (at least for today's hardware).
> >  > > I'm not convinced that adding this to DPMS is the way to go.
> >  > > Depending on what you need (see above) you may want to create
> >  > > a new extension. Apps can check if it is there and don't get
> >  > > confused by the presence of DPMS but the absense of these
> >  > > special features.
> >  >
> >  > some of the silicon motion chips have a similar mode.  It'd be nice to
> >  > design an extension where we can dynamically change this since, at
> >  > least on silicon motion, you have to disable the overlay, DAC, and
> >  > some other features to enable the low power idle mode.
> >  >
> >
> > In case of the silicon motion it would not keep the screen running.
> > In this case the powerdown could actually happen on a DPMS event.
> > I think a lot of mobile device chipsets have power save features
> > and also some parts of the desktop chips can be disabled when not
> > in use. We just have to learn how.
>
> It does keep the flatpanel running, but in a sort of locked
> self-refresh so you can power down the rest of the chip (ie, flatpanel
> only, no DAC).

I've been able to enable the these low power modes, but there's no
easy way to switch back and forth within a server generation (they
have some limitations, so you'd want to be abel to turn it on and
off), other than say hacking Xv attributes to do it.  Perhaps rather
than a new power management protocol we should work on a generic
driver attributes protocol.  It would allow us to implement common
attributes uniformly, and allow drivers to add support for on the fly
configuration of driver specific features.  It may also mesh nicely
with the new xrandr for dynamically enabling multi-head and such.

Alex

>
> Alex
>
> >
> > Cheers,
> >         Egbert.
> >
>



More information about the xorg mailing list