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, p...@laptop.org _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel