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

[Jim Gettys]

On Tue, 2006-08-08 at 16:26 +0200, Egbert Eich wrote:
> Jim Gettys writes:
>  > On Tue, 2006-08-08 at 11:39 +0200, Egbert Eich wrote:
>  > > Jim Gettys writes:
>  > >  > 
>  > >  > > Thats is a confusing thing.  In fact if the frame buffer is powered 
>  > >  > > down, the screen will be
>  > >  > > undefined.  i.e. not working.
>  > >  > 
>  > >  > This isn't true, and I'll give two counter examples:
>  > >  >    o E-Ink displays.
>  > >  >    o Our DCON driven display.
>  > > 
>  > > Right. This discussion went well beoyond your use case.
>  > > We looked at the default case with todays hardware.
>  > > Here is what I have been saying all along:
>  > > We need more input from hardware vendors what we can
>  > > realistically expect in the future. Are E-Ink displays
>  > > (as much as I would like to have it) something that
>  > > is going to happen?
>  > 
>  > To some degree, yes.  E-ink has the major feature of 0 power consumption
>  > with a stable image.  We see e-ink in a few e-book products at this date
>  > (the Sony LIBRie being the first, and there are others out there). So
>  > far, these are confined to e-books as e-ink doesn't refresh fast enough
>  > to be used for arbitrary applications.  This, along with cost and volume
>  > requirements, is why the OLPC system uses a TFT based design (though it
>  > is a novel TFT).
> 
> E-ink is so far only used for very specific purposes. OLPC is the first
> project that applies a very similar concept (based on a different technology)
> with similar limitations (only two colors) to a more general desktop 
> environment. 

Not just two colors: we can do exactly the same with full color.  The
display can continue live while the processor sleeps, in either b/w or
color mode.

>  > 
>  > Whether e-ink will be overtaken by other display technologies and/or
>  > becomes fast enough to compete head to head with TFT remains to be seen.
>  > What we've shown with our chip is that there are alternatives using
>  > conventional TFT display technology with good (if not quite so perfect)
>  > power savings.
>  > 
>  > So we now meet the criterion of more than one example (though in the
>  > e-ink case, you have no reason to bother to turn off the screen, since
>  > you don't get further power savings; if you blank an e-ink display, it
>  > is because you don't want the contents viewable rather than to save
>  > power).
> 
> Right.
> 
>  > 
>  > > As long as hardware vendors don't talk to us until it
>  > > is too late ("We need to release a driver that can do 
>  > > this and that by the end of next month") we can hardly
>  > > react and create an infrastrucutre.
>  > > 
>  > 
>  > Hey, we're talking to you (us).  And e-ink has been on the market (at a
>  > low level) for a year or two now.  I'm very aware of the situation
>  > here...
>  > 
>  > Now that X.org is up and running seriously, we (X.org) needs to
>  > transition from reactive mode to active engagement in technology
>  > development.
> 
> Yes, definitely!
> My rant wasn't aimed at you. I explicitely said so some lines further
> down. I know that OLPC is a project that is heavily communicating with
> the communicating as it is build on the concept of free software.
> 
>  > 
>  > >  > 
>  > >  > And there are other technologies being looked at that may make the
>  > >  > display able to be "live", which any ability to modify the image is
>  > >  > turned off.
>  > > 
>  > > Knowing that there will be a system with this feature
>  > > being deployed (the OLPC box) should provide sufficient
>  > > incentive to take this case into account in our design.
>  > 
>  > Yup.
> 
> Now the question remains what needs to be done in your case:
> 
> We use DPMS as a hint for the driver to disable certain parts of the
> chip. Furthermore it can be expected that the content is not visible
> on the screen - a circumstance which would allow the driver to enable
> even power savings that affect the signal output. 
> Also wakeup time is no issue as long as it doesn't exceed the wakeup 
> time that is expected for DPMS.
> However DPMS is not what you want for OLPC  when running in the 
> passively lit mode.

Or the color mode, I suspect.  While switching from color to monochrome
saves some power, it is the user's choice, and some applications will
require color to be useful.

> 
> Vice versa the driver may use internal timer counters to shut 
> down parts of the hardware depending on the display technology
> used, the frequency of screen content updates and the amount of 
> time required to get the chip back up and running - as long as 
> the screen content remains visible and the wakeup happens 
> transparently to the rest of the hardware. All this doesn't 
> require any additional communication between client and server.
> Just a driver specific config option (perferrably on the fly)
> to set a timeout value would be nice to have.

Exactly.  But as I don't know what the timeouts ought to be (and they
may well be moving targets as we improve the resume time on the
machine), I'd really like to set the timeouts from a client (not to
mention "rm -rf /etc/xorg.conf").


> 
> Can you thnk of anything else?
> 
> Cheers,
> 	Egbert.
-- 
Jim Gettys
One Laptop Per Child