announce: alternate power management

[pgf at laptop.org]

mikus wrote:
 > > configurable timeouts for screen dim and sleep.  the dim
 > > level is configurable.
 > 
 > My XO systems are plugged in to the AC, so I normally leave them 
 > running 24/7.  But in the middle of the night if I happen to walk 
 > by, I notice if they are acting as "light sources".  Two concerns 
 > (for which I don't know whether doing anything is feasible):
 > 
 >   -  Rawhide.  AFAIK there currently is no dimming support at all. 
 > I either have to power off such an XO overnight, or have to close 
 > the lid while the backlight is still lit.  It would be useful if 
 > rawhide supported dimming/shutting_off the screen when no one is 
 > looking at it (irrespective of whether the CPU is doing work or not).

i'm sure rawhide will gain a power management solution of some
sort.  probably ohmd will be added.  i wouldn't be surprised if
olpc-kbdshim and olpc-powerd would work fine as well, but if
you'd like to test that to confirm it, i wouldn't object.  ;-)

 >   -  Suspend.  It was functioning well only with Joyride - but I 
 > hope it gets implemented other places as well.  The problem is - the 
 > CPU may suspend because it is idle (and partly dim the screen), but 
 > the user may still continue looking at that screen (in color mode) 
 > while the XO is suspended.  After a decent interval at half-bright, 
 > it is reasonable to assume the user has "seen enough", and the 
 > screen could now be dimmed all the way off.  BUT since the system is 
 > "sleeping", the current implementation has no way to "wake up" the 
 > system just so it can execute 'screen dim' instructions.  The result 
 > is that if I don't intervene at the keyboard, my suspended (Joyride) 
 > XO's screen remains half-bright throughout the night.  I think it 

yes, clearly it would be good to have two (or maybe three) more
stages available for idleness.

we should be able to extend current behavior like this:

		dim (exists)
		sleep, screen on (exists)
		sleep, screen off (can't be done currently)
		shutdown (can't be done currently)

or, alternatively, this sequence, which is more like a "normal"
laptop behaves:
		dim
		screen off
		sleep, screen off
		shutdown (can't be done currently)

i think all but the last step could be done currently.

what's missing is a) a wakeup when closing the lid, and/or b) the
ability for the system to set an alarm clock with which to wake
up at some time in the future, in order to let it go back to
(a deeper) sleep.  i spoke with richard about the wakeup alarm
recently -- implementing this requires changes to both the EC
(embedded controller) and to the kernel.  but maybe we can push
something along.  it's a feature which has been long-planned, but
never finished.

 > counter-productive to suspend the rest of the system (to save 
 > power!) when no one is using it, but to leave the screen lit (still 
 > drawing power!) once it can be presumed no one is using it any more.
 > 
 > 
 > > different power behavior when in ebook mode (though detection
 > > may be unreliable -- i think the ebook switch suffers from
 > > some issues we previously noticed with the lid switch).
 > 
 > What issues ?  I thought the lid switch could be fooled by people 
 > with magnets - but that an actual "shut" would always be recognized 
 > as being a "shut" (and a failure to recognize an "open" could be 
 > overcome by momentarily pressing the power button).

the lid issues i was referring to are covered in #5703 and #7536.

  a) we get no wakeup when closing the lid, only opening.  i
     believe this is a regression from some time ago, possibly a
     result of the fixes described in #5703, but also possibly a
     side-effect of #7536.  (i haven't yet examined the actual
     code for either one to see what's going on.) this keeps us
     from noticing that the lid is being closed with the screen
     still on, and it stays like that.  (#7536 was a change to
     keep us from waking on lid close when the screen was off --
     in that case the wakeup was needless.)

  b) i've seen out-of-sync ebook switch behavior -- i.e., the event
     being reported (ebook open/close) exactly mismatches the
     physical condition of ebook mode.  since this behavior was
     described for the lid switch in #5703 (and fixed), i'm
     guessing the ebook switch needs similar love.  again, i
     haven't looked at the code yet.

  c) we still sometimes get "empty sci" as the wakeup source
     after a lid open.  i (in powerd) currently treat "empty sci"
     the same as "lid", but that might not fly if we were to fix a).

paul
=---------------------
 paul fox, pgf at laptop.org