Power manager specification... (request for comments).

[Jim Gettys]

On Fri, 2007-08-17 at 11:46 +0100, Richard Hughes wrote:
> On 15/08/07, Jim Gettys <jg at laptop.org> wrote:
> > Fpr general comment and discussion, the following is a list of things
> > cjb and I think should happen.  What are we missing?  Other opinions?
> 
> Sorry for getting to the conversation late, it's been a busy week.
> 
> > Actions that OHM should do:
> >
> > o On momentary power button:
> >   turn off screen, suspend machine, leave keyboard and wireless on;
> > keyboard/touchpad will cause instant on again.
> 
> Yup.
> 
> > o On lid close on battery, should turn off keyboard, turn off screen
> >   Then should suspend to RAM, including disabling and
> >   powering down wireless
> 
> Okay.
> 
> > o on lid close, on power, leave the machine on and running.
> 
> Not turn off the backlight?

Of course turn off the backlight.

> 
> > o On lid open, turn on keyboard, reset keyboard, resume from suspend,
> > turn wireless back on, tell NM to reassociate (maybe only after some
> > delay), try previous association first, of course...
> 
> Sure.
> 
> > o On ebook mode, should turn off keyboard
> 
> Turn off as in twiddle some bit to power it down, or just stop the input events?
> 
> > o On lid open, should reset keyboard
> > o on ebook to non-ebook mode, should reset keyboard
> 
> How?
> 

There is a keyboard command, that I think is in the trac issue on the
topic, on how to reset the keyboard; but there are actually two cases
here:

1) resetting the keyboard/touchpad when it has been powered up; this all
versions will do.  We should do this anytime external power is applied
or removed, or other major physical changes.

2) CTest and production touch pads can be set into a special extremely
low power mode, and save some 16mw, IIRC.  Bringing them out of this
state does a reset.  This is what we should do either when the machine
is suspended and the keyboard touch/pad is inaccessible.  It turns out
that while I'd been thinking of delaying bothering to go for this
minimal power savings, we have a problem in ebook mode where the buttons
can be pressed by accident if you squeeze, and it's too late to think
about physical changes to the machine.  So to fix that problem, we might
as well go ahead sooner rather than later.

> > o on external power supply on *or* off, should reset touchpad
> 
> Which command?
> 
> > o rotate should probably be done by OHM.
> 
> Totally agree. It's in the best position to enforce policy IMO.

It's really something a window manager, in combination with hints should
solve.

> 
> > When we are suspended, and the battery wakes us up because it is "low",
> > then:
> >         For now, graceful shutdown after journal has been notified
> 
> How do we notify the journal - OHM is system and the journal is session, no?
> 
> >         May do hibernation if enough flash is available.
> 
> Cool.
> 
> > Task: Tune the default DPMS parameters.
> >
> > Reset keyboard instructions are in trac.
> >
> > The big question is: how to do idle?
> >         X DPMS extension? X SS extension? cpuidle kernel patch, about to go
> > mainline in Linux, with module to tell ohm the system has been idle?
> > other ideas?
> 
> In g-p-m svn I've been using the idletime extension for some time now.
> It works well, with a few little quirks, although it only gives the
> user-activity point of idle, rather than the machine state idle.

Machine state idle is more complex, and may involve detailed knowledge
of whether USB devices are installed, for example.

Adam Belay's et. al.'s CPUidle work may (part of) be the solution here.
There is a patch for 2.6.22, and I think it's now in the -mm tree (or
maybe Linus's tree).  So we can probably eventually arrange to notify
OHM when the system seems to be in a decent state for suspend on idle,
and when it is not.
                                - Jim

-- 
Jim Gettys
One Laptop Per Child