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

[Egbert Eich]

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. 
 > 
 > 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.

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.

Can you thnk of anything else?

Cheers,
	Egbert.