Re: announce: alternate power management
This looks quite interesting. Have you looked at what Fedora is
introducing with DeviceKit-power and fellows in Fedora 11. It would be
interesting to see the similarities in features to help minimise
duplication of effort and to piggy back off Redhat's development
resources. They are using it to push alot of the functionality of
gnome-power-manager lower down into the stack which in turn means any
device such as servers/kde/whatever can make use of it. More details
can be seen here https://fedoraproject.org/wiki/Features/DeviceKit
Peter
On Fri, Mar 13, 2009 at 10:33 PM, p...@laptop.org wrote:
hi --
i had an itch that needed scratching, and the result is a
reimplementation of much (but not all) of what ohmd does
currently.
i've thought for some time (and i believe cjb agrees) that ohmd
is needlessly difficult to maintain and modify for our purposes
on the XO. small improvements are difficult to implement
quickly.
since my heart is with more quasi-embedded systems than the XO's
current incarnation, part of my goal was to do a rewrite which
was not dependent on hald, dbus, or X11 -- power management
should work well from a console screen, and be available even if
none of those services is running.
i call the service i wrote powerd. it gets user idle/active
reports from the olpc-kbdshim daemon (which is watching all
user keypress and touchpad activity in any case), and it gets
reports regarding the hardware inputs (power button, lid and
ebook switches, ac adapter status, battery level, etc) either
from another small daemon that monitors /dev/input/event{0,1,2},
or from /sys nodes directly.
it basically recreates ohmd's dim after a bit, then sleep
behavior, with some additions:
- a power button splash screen: a second press of the power
button invokes shutdown, simply waiting for a brief timeout
invokes suspend, and any user activity cancels. (i even
managed to kinda sorta convey all that with graphics. i'm
sure every UI person that sees it will roll their eyes.)
- configurable timeouts for screen dim and sleep. the dim
level is configurable.
- different power management behavior when on wall power vs.
battery -- many laptop owners don't need to be miserly with
power when running from an external source. powerd makes
this behavior selectable.
- 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). this
should let you configure things like a very short timeout until
idle-suspend, and/or no screen dimming, when in ebook mode. (i
find the frequent on/off nature of the backlight when reading
in ebook mode to be a distraction.)
- clean shutdown on critically low battery. (currently set at
a reported 5%, at which point my laptop would only run for
another couple of minutes.)
- the ability to run arbitrary scripts after a resume. (perhaps
to reinit usb devices that don't suspend/resume properly? haven't
used this much yet.)
- ease of customization, given that it's written in everyone's
favorite interpreted language.
unimplemented:
- inhibiting idle suspend based on system or network load.
i.e., the system will dim or suspend when watching a video.
(there are hooks in place where these features should be
implemented -- they're just not coded at all.) there's
no /etc/ohmd directory, so it honors /var/run/inhibit-idle-suspend
instead.
- no special support for the wireless mesh, whatsoever. i
couldn't remember how it was supposed to work, and i recall
cjb saying it's hard to figure out whether the mesh is active
or not.
- there's some support for wake-on-wlan, but it's not well tested.
finally a big one:
- proper support for USB keyboards and mice. i recently
realized that since olpc-kbdshim only monitors the built-in
keyboard and touchpad, powerd will think the user is idle
while they type on a USB keyboard, and cheerfully suspend
regardless. (in my case, most of the time i want to
auto-suspend is when i'm running on battery, and not using
external devices, so i sort of forgot about this case.)
anyway, code is available here:
http://dev.laptop.org/git/users/pgf/powerd/
and rpms are here:
http://dev.laptop.org/~pgf/rpms/
you'll need to install both olpc-kbdshim and olpc-powerd (in that
order). when installed, olpc-powerd disables ohmd, and reenables
it when uninstalled. (so it's relatively safe to try.)
there's no gui or other convenience for configuration --
see/etc/powerd/powerd.conf. the installed defaults should be
reasonable. and you'll need to run:
echo reconfig /var/run/powerevents
after making changes to the config file.
paul
=-
paul fox, p...@laptop.org
___
Devel mailing list
Re: announce: alternate power management
peter wrote:
This looks quite interesting. Have you looked at what Fedora is
introducing with DeviceKit-power and fellows in Fedora 11. It would be
interesting to see the similarities in features to help minimise
duplication of effort and to piggy back off Redhat's development
resources. They are using it to push alot of the functionality of
gnome-power-manager lower down into the stack which in turn means any
device such as servers/kde/whatever can make use of it. More details
can be seen here https://fedoraproject.org/wiki/Features/DeviceKit
that's the great thing about linux -- just when we finally
develop a standard way of doing things, someone steps in and
says, no, that was wrong, let's do it this way instead, and
stops supporting or improving the old way. i was just in the
process of reluctantly integrating olpc-kbdshim with hal, since
it turns out that's the path of least resistance to detecting
user activity on removeable USB devices. but now that i learn
that hal has been pronounced obsolescent, i suppose i'll just put
this all on the shelf for a year or two, and wait for the new
infrastructure to be ready.
that sarcasm aside, i see no reason that at some point powerd
couldn't use some of the facilities listed here:
http://hal.freedesktop.org/docs/DeviceKit-power/
as a means to become more generic. (at the cost of becoming
slower, of course -- we would be replacing simple reads of fixed
nodes in /sys with dbus calls to a daemon which would do those
simple reads of fixed nodes for us.)
my goal with powerd was simplicity, and with specific support of
the XO. there are some small complexities dealing with things
like USB devices, as mentioned above, and with making sure we can
put up splash screens in a timely manner, but overall, it really
is pretty simple. i don't intend (in the near term, if ever) to
balloon it with generic support for problems we don't have.
(especialy when it's not clear anyone will ever use it! :-)
thanks for the heads-up, though -- i wasn't aware of devicekit.
paul
Peter
On Fri, Mar 13, 2009 at 10:33 PM, p...@laptop.org wrote:
hi --
i had an itch that needed scratching, and the result is a
reimplementation of much (but not all) of what ohmd does
currently.
i've thought for some time (and i believe cjb agrees) that ohmd
is needlessly difficult to maintain and modify for our purposes
on the XO. small improvements are difficult to implement
quickly.
since my heart is with more quasi-embedded systems than the XO's
current incarnation, part of my goal was to do a rewrite which
was not dependent on hald, dbus, or X11 -- power management
should work well from a console screen, and be available even if
none of those services is running.
i call the service i wrote powerd. it gets user idle/active
reports from the olpc-kbdshim daemon (which is watching all
user keypress and touchpad activity in any case), and it gets
reports regarding the hardware inputs (power button, lid and
ebook switches, ac adapter status, battery level, etc) either
from another small daemon that monitors /dev/input/event{0,1,2},
or from /sys nodes directly.
it basically recreates ohmd's dim after a bit, then sleep
behavior, with some additions:
- a power button splash screen: a second press of the power
button invokes shutdown, simply waiting for a brief timeout
invokes suspend, and any user activity cancels. (i even
managed to kinda sorta convey all that with graphics. i'm
sure every UI person that sees it will roll their eyes.)
- configurable timeouts for screen dim and sleep. the dim
level is configurable.
- different power management behavior when on wall power vs.
battery -- many laptop owners don't need to be miserly with
power when running from an external source. powerd makes
this behavior selectable.
- 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). this
should let you configure things like a very short timeout until
idle-suspend, and/or no screen dimming, when in ebook mode. (i
find the frequent on/off nature of the backlight when reading
in ebook mode to be a distraction.)
- clean shutdown on critically low battery. (currently set at
a reported 5%, at which point my laptop would only run for
another couple of minutes.)
- the ability to run arbitrary scripts after a resume. (perhaps
to reinit usb devices that don't suspend/resume properly? haven't
used this much yet.)
- ease of customization, given that it's written in everyone's
favorite interpreted language.
unimplemented:
- inhibiting idle suspend based on system or network load.
i.e., the system will dim
Re: announce: alternate power management
pgf writes: so: i've packaged a new version of powerd. the big change is that it now allows for the two modes of operation i mentioned last week on the list: dim sleep, screen on sleep, screen off shutdown or: dim screen off sleep, screen off shutdown screen on and screen off aren't very well defined. What exactly do you mean? a. the Geode chipset: producing video or not? b. the DCON: pass-through, freeze-frame, or off? c. the backlight: on or off? d. the LCD panel: on or off? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: announce: alternate power management
albert wrote: pgf writes: so: i've packaged a new version of powerd. the big change is that it now allows for the two modes of operation i mentioned last week on the list: dim sleep, screen on sleep, screen off shutdown or: dim screen off sleep, screen off shutdown screen on and screen off aren't very well defined. What exactly do you mean? sorry -- i was describing it from a naive user's perspective. here: dim(reduced backlight) sleep, screen on (cpu sleep, dcon on, backlight still on and dim) sleep, screen off (cpu sleep, dcon off, backlight off) shutdown or: dim(reduced backlight) screen off (cpu running, dcon off, backlight off) sleep, screen off (cpu sleep, dcon off, backlight off) shutdown the two cases are diffentiated by powerd simply by looking at the middle two timers -- if the timer for sleeping is smaller than the timer for turning hte screen off, you get the first set of steps, otherwise the second. (btw, probably obvious, but any trailing subset of these steps can be supressed simply by setting the appropriate timeout arbitrarily high.) a. the Geode chipset: producing video or not? i don't believe anything explicit for this is done (except shutdown and cpu sleep, of course). i'm not sure how to accomplish this. b. the DCON: pass-through, freeze-frame, or off? the dcon is frozen while the shutdown splash screen(s) are painting, so that you can't see the shades coming down. other than that, it remains unfrozen, but is turned on and off as noted above. c. the backlight: on or off? turned on and off as above. when dimming, the level being ramped to is configurable, so if you set it to 15, no dimming will occur. d. the LCD panel: on or off? i confess i don't know how to do that. if it's feasible, and not happening already, it should be added. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: announce: alternate power management
okay, if i don't quit playing with this thing and get the taxes
done, my wife will kill me.
so: i've packaged a new version of powerd. the big change
is that it now allows for the two modes of operation i mentioned
last week on the list:
dim
sleep, screen on
sleep, screen off
shutdown
or:
dim
screen off
sleep, screen off
shutdown
(in contrast, the current releases only really support
dim
sleep, screen on
after that you have to do things manually.)
in addition, powerd can use a completely different configuration
profile when running in ebook mode -- in fact, you can have multiple
profiles (you know you've always wanted a different power behavior
when taking your laptop to the beach, right?) and switch between
them pretty easily.
there's also a (very) primitive configuration utility that lets
you select the major configuration parameters. (it's dialog-based,
so it's curses-based graphics. you've been warned.)
by default, power management is only active when you're running
on battery. that's selectable.
the big items listed under unimplemented down below are still
unimplemented. don't know when i'll get to them.
enjoy. please try it, please let me know what you find. i've
seen a few anomolies while playing with it -- most of which i
think i've fixed. but there may well be more, since i think i've
seen at least one i still can't really explain. (but it was
after a couple of glasses of wine, so who knows.)
code:
http://dev.laptop.org/git/users/pgf/powerd/
rpms:
http://dev.laptop.org/~pgf/rpms/
paul
p...@laptop.org wrote:
hi --
i had an itch that needed scratching, and the result is a
reimplementation of much (but not all) of what ohmd does
currently.
i've thought for some time (and i believe cjb agrees) that ohmd
is needlessly difficult to maintain and modify for our purposes
on the XO. small improvements are difficult to implement
quickly.
since my heart is with more quasi-embedded systems than the XO's
current incarnation, part of my goal was to do a rewrite which
was not dependent on hald, dbus, or X11 -- power management
should work well from a console screen, and be available even if
none of those services is running.
i call the service i wrote powerd. it gets user idle/active
reports from the olpc-kbdshim daemon (which is watching all
user keypress and touchpad activity in any case), and it gets
reports regarding the hardware inputs (power button, lid and
ebook switches, ac adapter status, battery level, etc) either
from another small daemon that monitors /dev/input/event{0,1,2},
or from /sys nodes directly.
it basically recreates ohmd's dim after a bit, then sleep
behavior, with some additions:
- a power button splash screen: a second press of the power
button invokes shutdown, simply waiting for a brief timeout
invokes suspend, and any user activity cancels. (i even
managed to kinda sorta convey all that with graphics. i'm
sure every UI person that sees it will roll their eyes.)
- configurable timeouts for screen dim and sleep. the dim
level is configurable.
- different power management behavior when on wall power vs.
battery -- many laptop owners don't need to be miserly with
power when running from an external source. powerd makes
this behavior selectable.
- 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). this
should let you configure things like a very short timeout until
idle-suspend, and/or no screen dimming, when in ebook mode. (i
find the frequent on/off nature of the backlight when reading
in ebook mode to be a distraction.)
- clean shutdown on critically low battery. (currently set at
a reported 5%, at which point my laptop would only run for
another couple of minutes.)
- the ability to run arbitrary scripts after a resume. (perhaps
to reinit usb devices that don't suspend/resume properly? haven't
used this much yet.)
- ease of customization, given that it's written in everyone's
favorite interpreted language.
unimplemented:
- inhibiting idle suspend based on system or network load.
i.e., the system will dim or suspend when watching a video.
(there are hooks in place where these features should be
implemented -- they're just not coded at all.) there's
no /etc/ohmd directory, so it honors /var/run/inhibit-idle-suspend
instead.
- no special support for the wireless mesh, whatsoever. i
couldn't remember how it was supposed to work, and i recall
cjb saying it's hard to figure out
Re: announce: alternate power management
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. ;-) Rawhide status: thanks for testing! 1. Only by using an OLPC kernel (such as the one from staging release 801) is the kernel is capable of power management on the XO 2. with an OLPC kernel, ohmd does not work. Closing the lid, hitting the power button, these are not detected. I don't know why at the moment... odd. ohmd uses dbus for various things, but i would have assumed that would work. Does it deal with the new dbus security stuff which has been enabled recently in rawhide? Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: announce: alternate power management
On Sun, 2009-03-15 at 00:37 -0400, p...@laptop.org wrote: scott wrote: 3. with the OLPC kernel and this olpc-kbdshim and olpc-powerd (which by the way are really realy nice, thanks a million pgf!) the XO suspends when via lid switch and the power button. great! did you try the grab keys and rotation? (those are just olpc-kbdshim.) olpc-rotate should spin the display, even if the buttons don't work. Pressing the rotation button does nothing in GNOME or Sugar. Should this be a general X rotation that should work in any X session? hmm. i wouldn't expect the button to work in gnome, but i'd expect the sugar bindings to continue working. the first check, though, it to see if the olpc-rotate command works from terminal. when olpc-kbdshim installs, it patches sugar to run that command rather than do its normal internal calls to xrandr. so if the command works, but the key doesn't, the debug path is pretty short, at least, i think. (is is possible that sugar installed after olpc-kbdshim? that would explain it.) In both GNOME and Sugar, the olpc-rotate command leaves the XO with a black screen. The virtual terminal keys may be working in this state, but the screen stays black so it's hard to tell! I found that suspending, then coming back, enabled me to get a virtual terminal so I could do the init 3; init 5 dance and restore X. What are grab keys? I am not seeing any functionality for the gamepad keys. In the OLPC Fedora/Sugar these enable me to get around the scroll bar is not draw even though content is larger than frame fun. the grab keys are the two with the little hands, at either side of the space bar. on an industry standard keyboard, they would be the bear the industry monopolist logo. :-) when you hold either down, a using the touchpad should cause whatever you're looking at to scroll. (if it's capable, of course -- i.e., wide or tall web pages, or terminal sessions with any amount of scrollback.) Grab keys are working as you described in GNOME and Sugar. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] announce: alternate power management
On Sat, Mar 14, 2009 at 11:37 PM, p...@laptop.org wrote: scott wrote: 3. with the OLPC kernel and this olpc-kbdshim and olpc-powerd (which by the way are really realy nice, thanks a million pgf!) the XO suspends when via lid switch and the power button. great! did you try the grab keys and rotation? (those are just olpc-kbdshim.) olpc-rotate should spin the display, even if the buttons don't work. Pressing the rotation button does nothing in GNOME or Sugar. Should this be a general X rotation that should work in any X session? hmm. i wouldn't expect the button to work in gnome, but i'd expect the sugar bindings to continue working. the first check, though, it to see if the olpc-rotate command works from terminal. when olpc-kbdshim installs, it patches sugar to run that command rather than do its normal internal calls to xrandr. so if the command works, but the key doesn't, the debug path is pretty short, at least, i think. (is is possible that sugar installed after olpc-kbdshim? that would explain it.) What are grab keys? I am not seeing any functionality for the gamepad keys. In the OLPC Fedora/Sugar these enable me to get around the scroll bar is not draw even though content is larger than frame fun. the grab keys are the two with the little hands, at either side of the space bar. on an industry standard keyboard, they would be the bear the industry monopolist logo. :-) when you hold either down, a using the touchpad should cause whatever you're looking at to scroll. (if it's capable, of course -- i.e., wide or tall web pages, or terminal sessions with any amount of scrollback.) 4. In a GNOME session, this behaves oddly, as gnome-power-manager also intercepts the power button press and pops up a hibernate/suspend/yadayada/ dialog, and then your XO suspends anyway :-) yeah, i kind of expected that. similar issues happen if you run ohmd alongside powerd as well. is g-p-m (easily) uninstallable? Yes. Very easy to remove. One additional point related to power management, the control panel in the current Sugar RPMs (for rawhide/F11) doesn't have the power settings (extreme power management etc.) icon. Perhaps there is a gconf key to enable that? I asked in #sugar but got no reply. Or, is this functionality removed on purpose? don't know. i have several questions about how XO-specific hardware will be supported going forward. i assume the sugar folks would rather not continue carrying hardware specific key-bindings for rotation and brightness for instance, but i don't know what their current thoughts are. On the other hand, any advances that can be abstracted enough to advance the usability of net-books in general is welcome:) While Sugar Labs might not be the final landing place for the technology, it might be a better upstream or downstream fit, you are more then welcome to test and develop here. It the tech is useful, we will integrate it or help you push it up or down stream as necessary. david paul =- paul fox, p...@laptop.org ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: announce: alternate power management
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
Re: announce: alternate power management
i wrote: 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. i've now looked at the code -- ebook mode tracking is completely separate from and different than lid state tracking. (sigh :-) it seems the condition i saw could be caused by an early failed read of the ebook state by the kernel, or a subsequent loss of one of the SCI events which indicates that the state changed. (this is a really good example of why just reporting something has changed, without reporting what it has changed _to_, is a bad idea from a robustness point of view.) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: announce: alternate power management
On Sat, 2009-03-14 at 09:37 -0400, p...@laptop.org wrote: mikus wrote: - 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. ;-) Rawhide status: 1. Only by using an OLPC kernel (such as the one from staging release 801) is the kernel is capable of power management on the XO 2. with an OLPC kernel, ohmd does not work. Closing the lid, hitting the power button, these are not detected. I don't know why at the moment... 3. with the OLPC kernel and this olpc-kbdshim and olpc-powerd (which by the way are really realy nice, thanks a million pgf!) the XO suspends when via lid switch and the power button. 4. In a GNOME session, this behaves oddly, as gnome-power-manager also intercepts the power button press and pops up a hibernate/suspend/yadayada/ dialog, and then your XO suspends anyway :-) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: announce: alternate power management
scott wrote: On Sat, 2009-03-14 at 09:37 -0400, p...@laptop.org wrote: 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. ;-) Rawhide status: thanks for testing! 1. Only by using an OLPC kernel (such as the one from staging release 801) is the kernel is capable of power management on the XO 2. with an OLPC kernel, ohmd does not work. Closing the lid, hitting the power button, these are not detected. I don't know why at the moment... odd. ohmd uses dbus for various things, but i would have assumed that would work. 3. with the OLPC kernel and this olpc-kbdshim and olpc-powerd (which by the way are really realy nice, thanks a million pgf!) the XO suspends when via lid switch and the power button. great! did you try the grab keys and rotation? (those are just olpc-kbdshim.) olpc-rotate should spin the display, even if the buttons don't work. 4. In a GNOME session, this behaves oddly, as gnome-power-manager also intercepts the power button press and pops up a hibernate/suspend/yadayada/ dialog, and then your XO suspends anyway :-) yeah, i kind of expected that. similar issues happen if you run ohmd alongside powerd as well. is g-p-m (easily) uninstallable? paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: announce: alternate power management
3. with the OLPC kernel and this olpc-kbdshim and olpc-powerd (which by the way are really realy nice, thanks a million pgf!) the XO suspends when via lid switch and the power button. great! did you try the grab keys and rotation? (those are just olpc-kbdshim.) olpc-rotate should spin the display, even if the buttons don't work. Pressing the rotation button does nothing in GNOME or Sugar. Should this be a general X rotation that should work in any X session? What are grab keys? I am not seeing any functionality for the gamepad keys. In the OLPC Fedora/Sugar these enable me to get around the scroll bar is not draw even though content is larger than frame fun. 4. In a GNOME session, this behaves oddly, as gnome-power-manager also intercepts the power button press and pops up a hibernate/suspend/yadayada/ dialog, and then your XO suspends anyway :-) yeah, i kind of expected that. similar issues happen if you run ohmd alongside powerd as well. is g-p-m (easily) uninstallable? Yes. Very easy to remove. One additional point related to power management, the control panel in the current Sugar RPMs (for rawhide/F11) doesn't have the power settings (extreme power management etc.) icon. Perhaps there is a gconf key to enable that? I asked in #sugar but got no reply. Or, is this functionality removed on purpose? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: announce: alternate power management
scott wrote: 3. with the OLPC kernel and this olpc-kbdshim and olpc-powerd (which by the way are really realy nice, thanks a million pgf!) the XO suspends when via lid switch and the power button. great! did you try the grab keys and rotation? (those are just olpc-kbdshim.) olpc-rotate should spin the display, even if the buttons don't work. Pressing the rotation button does nothing in GNOME or Sugar. Should this be a general X rotation that should work in any X session? hmm. i wouldn't expect the button to work in gnome, but i'd expect the sugar bindings to continue working. the first check, though, it to see if the olpc-rotate command works from terminal. when olpc-kbdshim installs, it patches sugar to run that command rather than do its normal internal calls to xrandr. so if the command works, but the key doesn't, the debug path is pretty short, at least, i think. (is is possible that sugar installed after olpc-kbdshim? that would explain it.) What are grab keys? I am not seeing any functionality for the gamepad keys. In the OLPC Fedora/Sugar these enable me to get around the scroll bar is not draw even though content is larger than frame fun. the grab keys are the two with the little hands, at either side of the space bar. on an industry standard keyboard, they would be the bear the industry monopolist logo. :-) when you hold either down, a using the touchpad should cause whatever you're looking at to scroll. (if it's capable, of course -- i.e., wide or tall web pages, or terminal sessions with any amount of scrollback.) 4. In a GNOME session, this behaves oddly, as gnome-power-manager also intercepts the power button press and pops up a hibernate/suspend/yadayada/ dialog, and then your XO suspends anyway :-) yeah, i kind of expected that. similar issues happen if you run ohmd alongside powerd as well. is g-p-m (easily) uninstallable? Yes. Very easy to remove. One additional point related to power management, the control panel in the current Sugar RPMs (for rawhide/F11) doesn't have the power settings (extreme power management etc.) icon. Perhaps there is a gconf key to enable that? I asked in #sugar but got no reply. Or, is this functionality removed on purpose? don't know. i have several questions about how XO-specific hardware will be supported going forward. i assume the sugar folks would rather not continue carrying hardware specific key-bindings for rotation and brightness for instance, but i don't know what their current thoughts are. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
announce: alternate power management
hi --
i had an itch that needed scratching, and the result is a
reimplementation of much (but not all) of what ohmd does
currently.
i've thought for some time (and i believe cjb agrees) that ohmd
is needlessly difficult to maintain and modify for our purposes
on the XO. small improvements are difficult to implement
quickly.
since my heart is with more quasi-embedded systems than the XO's
current incarnation, part of my goal was to do a rewrite which
was not dependent on hald, dbus, or X11 -- power management
should work well from a console screen, and be available even if
none of those services is running.
i call the service i wrote powerd. it gets user idle/active
reports from the olpc-kbdshim daemon (which is watching all
user keypress and touchpad activity in any case), and it gets
reports regarding the hardware inputs (power button, lid and
ebook switches, ac adapter status, battery level, etc) either
from another small daemon that monitors /dev/input/event{0,1,2},
or from /sys nodes directly.
it basically recreates ohmd's dim after a bit, then sleep
behavior, with some additions:
- a power button splash screen: a second press of the power
button invokes shutdown, simply waiting for a brief timeout
invokes suspend, and any user activity cancels. (i even
managed to kinda sorta convey all that with graphics. i'm
sure every UI person that sees it will roll their eyes.)
- configurable timeouts for screen dim and sleep. the dim
level is configurable.
- different power management behavior when on wall power vs.
battery -- many laptop owners don't need to be miserly with
power when running from an external source. powerd makes
this behavior selectable.
- 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). this
should let you configure things like a very short timeout until
idle-suspend, and/or no screen dimming, when in ebook mode. (i
find the frequent on/off nature of the backlight when reading
in ebook mode to be a distraction.)
- clean shutdown on critically low battery. (currently set at
a reported 5%, at which point my laptop would only run for
another couple of minutes.)
- the ability to run arbitrary scripts after a resume. (perhaps
to reinit usb devices that don't suspend/resume properly? haven't
used this much yet.)
- ease of customization, given that it's written in everyone's
favorite interpreted language.
unimplemented:
- inhibiting idle suspend based on system or network load.
i.e., the system will dim or suspend when watching a video.
(there are hooks in place where these features should be
implemented -- they're just not coded at all.) there's
no /etc/ohmd directory, so it honors /var/run/inhibit-idle-suspend
instead.
- no special support for the wireless mesh, whatsoever. i
couldn't remember how it was supposed to work, and i recall
cjb saying it's hard to figure out whether the mesh is active
or not.
- there's some support for wake-on-wlan, but it's not well tested.
finally a big one:
- proper support for USB keyboards and mice. i recently
realized that since olpc-kbdshim only monitors the built-in
keyboard and touchpad, powerd will think the user is idle
while they type on a USB keyboard, and cheerfully suspend
regardless. (in my case, most of the time i want to
auto-suspend is when i'm running on battery, and not using
external devices, so i sort of forgot about this case.)
anyway, code is available here:
http://dev.laptop.org/git/users/pgf/powerd/
and rpms are here:
http://dev.laptop.org/~pgf/rpms/
you'll need to install both olpc-kbdshim and olpc-powerd (in that
order). when installed, olpc-powerd disables ohmd, and reenables
it when uninstalled. (so it's relatively safe to try.)
there's no gui or other convenience for configuration --
see/etc/powerd/powerd.conf. the installed defaults should be
reasonable. and you'll need to run:
echo reconfig /var/run/powerevents
after making changes to the config file.
paul
=-
paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] announce: alternate power management
Very cool!
How well will this integrate with the power management systems other
distros are using? Can it become a 'Value Added' for other netbook
manufacturers?
david
On Fri, Mar 13, 2009 at 4:33 PM, p...@laptop.org wrote:
hi --
i had an itch that needed scratching, and the result is a
reimplementation of much (but not all) of what ohmd does
currently.
i've thought for some time (and i believe cjb agrees) that ohmd
is needlessly difficult to maintain and modify for our purposes
on the XO. small improvements are difficult to implement
quickly.
since my heart is with more quasi-embedded systems than the XO's
current incarnation, part of my goal was to do a rewrite which
was not dependent on hald, dbus, or X11 -- power management
should work well from a console screen, and be available even if
none of those services is running.
i call the service i wrote powerd. it gets user idle/active
reports from the olpc-kbdshim daemon (which is watching all
user keypress and touchpad activity in any case), and it gets
reports regarding the hardware inputs (power button, lid and
ebook switches, ac adapter status, battery level, etc) either
from another small daemon that monitors /dev/input/event{0,1,2},
or from /sys nodes directly.
it basically recreates ohmd's dim after a bit, then sleep
behavior, with some additions:
- a power button splash screen: a second press of the power
button invokes shutdown, simply waiting for a brief timeout
invokes suspend, and any user activity cancels. (i even
managed to kinda sorta convey all that with graphics. i'm
sure every UI person that sees it will roll their eyes.)
- configurable timeouts for screen dim and sleep. the dim
level is configurable.
- different power management behavior when on wall power vs.
battery -- many laptop owners don't need to be miserly with
power when running from an external source. powerd makes
this behavior selectable.
- 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). this
should let you configure things like a very short timeout until
idle-suspend, and/or no screen dimming, when in ebook mode. (i
find the frequent on/off nature of the backlight when reading
in ebook mode to be a distraction.)
- clean shutdown on critically low battery. (currently set at
a reported 5%, at which point my laptop would only run for
another couple of minutes.)
- the ability to run arbitrary scripts after a resume. (perhaps
to reinit usb devices that don't suspend/resume properly? haven't
used this much yet.)
- ease of customization, given that it's written in everyone's
favorite interpreted language.
unimplemented:
- inhibiting idle suspend based on system or network load.
i.e., the system will dim or suspend when watching a video.
(there are hooks in place where these features should be
implemented -- they're just not coded at all.) there's
no /etc/ohmd directory, so it honors /var/run/inhibit-idle-suspend
instead.
- no special support for the wireless mesh, whatsoever. i
couldn't remember how it was supposed to work, and i recall
cjb saying it's hard to figure out whether the mesh is active
or not.
- there's some support for wake-on-wlan, but it's not well tested.
finally a big one:
- proper support for USB keyboards and mice. i recently
realized that since olpc-kbdshim only monitors the built-in
keyboard and touchpad, powerd will think the user is idle
while they type on a USB keyboard, and cheerfully suspend
regardless. (in my case, most of the time i want to
auto-suspend is when i'm running on battery, and not using
external devices, so i sort of forgot about this case.)
anyway, code is available here:
http://dev.laptop.org/git/users/pgf/powerd/
and rpms are here:
http://dev.laptop.org/~pgf/rpms/
you'll need to install both olpc-kbdshim and olpc-powerd (in that
order). when installed, olpc-powerd disables ohmd, and reenables
it when uninstalled. (so it's relatively safe to try.)
there's no gui or other convenience for configuration --
see/etc/powerd/powerd.conf. the installed defaults should be
reasonable. and you'll need to run:
echo reconfig /var/run/powerevents
after making changes to the config file.
paul
=-
paul fox, p...@laptop.org
___
Sugar-devel mailing list
sugar-de...@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] announce: alternate power management
david wrote:
Very cool!
How well will this integrate with the power management systems other
distros are using? Can it become a 'Value Added' for other netbook
manufacturers?
while i'd love to say i did a lot of research and prep in order
to make sure my little project was api compliant and future
compatible with other power management systems, i can't say that.
my goal's were small: to produce a lighter weight skeleton on
which to hang XO power management, in order to reduce the effort
needed to add some small features (that i wanted) to the current
functionality, and to make sure it was distro, desktop, and UI
independent. (i also wanted to prove to myself that it could
really be done the way i was picturing it).
paul
david
On Fri, Mar 13, 2009 at 4:33 PM, p...@laptop.org wrote:
hi --
i had an itch that needed scratching, and the result is a
reimplementation of much (but not all) of what ohmd does
currently.
i've thought for some time (and i believe cjb agrees) that ohmd
is needlessly difficult to maintain and modify for our purposes
on the XO. Â small improvements are difficult to implement
quickly.
since my heart is with more quasi-embedded systems than the XO's
current incarnation, part of my goal was to do a rewrite which
was not dependent on hald, dbus, or X11 -- power management
should work well from a console screen, and be available even if
none of those services is running.
i call the service i wrote powerd. Â it gets user idle/active
reports from the olpc-kbdshim daemon (which is watching all
user keypress and touchpad activity in any case), and it gets
reports regarding the hardware inputs (power button, lid and
ebook switches, ac adapter status, battery level, etc) either
from another small daemon that monitors /dev/input/event{0,1,2},
or from /sys nodes directly.
it basically recreates ohmd's dim after a bit, then sleep
behavior, with some additions:
 - a power button splash screen:  a second press of the power
  button invokes shutdown, simply waiting for a brief timeout
  invokes suspend, and any user activity cancels.  (i even
  managed to kinda sorta convey all that with graphics.  i'm
  sure every UI person that sees it will roll their eyes.)
 - configurable timeouts for screen dim and sleep.  the dim
  level is configurable.
 - different power management behavior when on wall power vs.
  battery -- many laptop owners don't need to be miserly with
  power when running from an external source.  powerd makes
  this behavior selectable.
 - 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).  this
  should let you configure things like a very short timeout until
  idle-suspend, and/or no screen dimming, when in ebook mode.  (i
  find the frequent on/off nature of the backlight when reading
  in ebook mode to be a distraction.)
 - clean shutdown on critically low battery.  (currently set at
  a reported 5%, at which point my laptop would only run for
  another couple of minutes.)
 - the ability to run arbitrary scripts after a resume.  (perhaps
  to reinit usb devices that don't suspend/resume properly?  haven't
  used this much yet.)
 - ease of customization, given that it's written in everyone's
  favorite interpreted language.
 unimplemented:
 - inhibiting idle suspend based on system or network load.
  i.e., the system will dim or suspend when watching a video.
  (there are hooks in place where these features should be
  implemented -- they're just not coded at all.)  there's
  no /etc/ohmd directory, so it honors /var/run/inhibit-idle-suspend
  instead.
 - no special support for the wireless mesh, whatsoever.  i
  couldn't remember how it was supposed to work, and i recall
  cjb saying it's hard to figure out whether the mesh is active
  or not.
 - there's some support for wake-on-wlan, but it's not well tested.
 finally a big one:
 - proper support for USB keyboards and mice.  i recently
  realized that since olpc-kbdshim only monitors the built-in
  keyboard and touchpad, powerd will think the user is idle
  while they type on a USB keyboard, and cheerfully suspend
  regardless.  (in my case, most of the time i want to
  auto-suspend is when i'm running on battery, and not using
  external devices, so i sort of forgot about this case.)
anyway, code is available here:
  http://dev.laptop.org/git/users/pgf/powerd/
and rpms are here:
  http://dev.laptop.org/~pgf/rpms/
you'll need to install both olpc-kbdshim and olpc-powerd
Re: announce: alternate power management
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). - 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 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). mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
