Power manager specification... (request for comments).
gnu at toad.com
Sat Aug 18 06:26:19 EDT 2007
The laptop should generally not act differently depending whether
there is external power. Too many people seem to be assuming that any
form of external power is "AC power" (i.e. a national power grid).
In the presence of limited external power, e.g. a car battery, a human
powered charger, a solar charger, a 220V gasoline generator, or a
flaky power grid that comes and goes, the laptop should never go out
of its "save power" mode. Feeding it power to charge its battery
should not cause it to consume more power than it otherwise would!
E.g. the screen brightness should never depend on whether there's external
E.g. when closing the lid, with or without external power, the laptop
should turn off the keyboard and touchpad and screen and backlight and
USB and SD and NAND, and force a suspend to RAM. (At least until
suspend-to-NAND is implemented.)
Whether closing the lid turns off the wireless chip is not a concern
of mine. If the wireless is left enabled for mesh forwarding, a
closed=suspended laptop should not awaken because a packet arrives.
You want the laptop to *stay* suspended when closed; if an application
like eToys or Web is active, it will otherwise never go idle
(animating the screen and burning up the battery).
Hmm, I wonder if X could declare that a physically closed laptop's
screen has become hidden behind another window (i.e. the front
application goes into the background). If this won't stop every
existing app from trying to update its window, then fix those
applications to stop drawing in the background!
[Can we create a "null activity" for testing, which clears the screen
and then does nothing but obscure the other running activities?
This would allow testing of the above, without physically closing the
Closing the cover and suspending should always sync all filesystems
first. Ideally it should not only sync them, but mark them as clean
(the first write after resuming would have to mark them dirty again).
Regarding how to do "idle" (is this suspend to RAM?), I think OLPC
should really try doing what it has always claimed to want to do:
suspend the CPU when nothing in the kernel is scheduled to happen for
a second or two (or more). The only way to see how well it works is
to try it. And if it doesn't work well, we'll learn what hardware
improvements are needed to make it work well (for Gen 2's even lower
Kludging up specific applications and ohm to try to "guess" when no
process will want to be running is overly complex and error-prone. If
the kernel doesn't already know the answer, it ought to. The reason
it was hacked into the ebook reader for a demo is because at that
time, the rest of the system wasn't smart enough to stop running when
it had nothing to do.
More information about the Devel