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, 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 languag
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, 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
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
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
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
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: [Sugar-devel] announce: alternate power management
On Sat, Mar 14, 2009 at 11:37 PM, 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
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: 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
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: > 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
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
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
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
> 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
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, 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: > > Â Â
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, 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
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