Power manager specification... (request for comments).
The laptop should generally not act differently depending whether there is external power. Too many people seem to be assuming that any form of external power is "AC power" (i.e. a national power grid). In the presence of limited external power, e.g. a car battery, a human powered charger, a solar charger, a 220V gasoline generator, or a flaky power grid that comes and goes, the laptop should never go out of its "save power" mode. Feeding it power to charge its battery should not cause it to consume more power than it otherwise would! E.g. the screen brightness should never depend on whether there's external power. E.g. when closing the lid, with or without external power, the laptop should turn off the keyboard and touchpad and screen and backlight and USB and SD and NAND, and force a suspend to RAM. (At least until suspend-to-NAND is implemented.) Whether closing the lid turns off the wireless chip is not a concern of mine. If the wireless is left enabled for mesh forwarding, a closed=suspended laptop should not awaken because a packet arrives. You want the laptop to *stay* suspended when closed; if an application like eToys or Web is active, it will otherwise never go idle (animating the screen and burning up the battery). Hmm, I wonder if X could declare that a physically closed laptop's screen has become hidden behind another window (i.e. the front application goes into the background). If this won't stop every existing app from trying to update its window, then fix those applications to stop drawing in the background! [Can we create a "null activity" for testing, which clears the screen and then does nothing but obscure the other running activities? This would allow testing of the above, without physically closing the screen.] Closing the cover and suspending should always sync all filesystems first. Ideally it should not only sync them, but mark them as clean (the first write after resuming would have to mark them dirty again). Regarding how to do "idle" (is this suspend to RAM?), I think OLPC should really try doing what it has always claimed to want to do: suspend the CPU when nothing in the kernel is scheduled to happen for a second or two (or more). The only way to see how well it works is to try it. And if it doesn't work well, we'll learn what hardware improvements are needed to make it work well (for Gen 2's even lower power consumption). Kludging up specific applications and ohm to try to "guess" when no process will want to be running is overly complex and error-prone. If the kernel doesn't already know the answer, it ought to. The reason it was hacked into the ebook reader for a demo is because at that time, the rest of the system wasn't smart enough to stop running when it had nothing to do. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power manager specification... (request for comments).
On Fri, 2007-08-17 at 12:57 +0200, Tomeu Vizoso wrote: > Hi, > > On Wed, 2007-08-15 at 16:01 -0400, Jim Gettys wrote: > > When we are suspended, and the battery wakes us up because it is > > "low", > > then: > > For now, graceful shutdown after journal has been notified > > May do hibernation if enough flash is available. > > I guess what we want here is to notify to each activity that they should > save their state to the datastore. Correct? > > How much time do we have until the system really shuts off? Heh. We'll probably have to have a protocol saying "it's ok now". You'll potentially have seconds or up to a minute. - Jim -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power manager specification... (request for comments).
On Fri, 2007-08-17 at 11:46 +0100, Richard Hughes wrote: > On 15/08/07, Jim Gettys <[EMAIL PROTECTED]> wrote: > > Fpr general comment and discussion, the following is a list of things > > cjb and I think should happen. What are we missing? Other opinions? > > Sorry for getting to the conversation late, it's been a busy week. > > > Actions that OHM should do: > > > > o On momentary power button: > > turn off screen, suspend machine, leave keyboard and wireless on; > > keyboard/touchpad will cause instant on again. > > Yup. > > > o On lid close on battery, should turn off keyboard, turn off screen > > Then should suspend to RAM, including disabling and > > powering down wireless > > Okay. > > > o on lid close, on power, leave the machine on and running. > > Not turn off the backlight? Of course turn off the backlight. > > > o On lid open, turn on keyboard, reset keyboard, resume from suspend, > > turn wireless back on, tell NM to reassociate (maybe only after some > > delay), try previous association first, of course... > > Sure. > > > o On ebook mode, should turn off keyboard > > Turn off as in twiddle some bit to power it down, or just stop the input > events? > > > o On lid open, should reset keyboard > > o on ebook to non-ebook mode, should reset keyboard > > How? > There is a keyboard command, that I think is in the trac issue on the topic, on how to reset the keyboard; but there are actually two cases here: 1) resetting the keyboard/touchpad when it has been powered up; this all versions will do. We should do this anytime external power is applied or removed, or other major physical changes. 2) CTest and production touch pads can be set into a special extremely low power mode, and save some 16mw, IIRC. Bringing them out of this state does a reset. This is what we should do either when the machine is suspended and the keyboard touch/pad is inaccessible. It turns out that while I'd been thinking of delaying bothering to go for this minimal power savings, we have a problem in ebook mode where the buttons can be pressed by accident if you squeeze, and it's too late to think about physical changes to the machine. So to fix that problem, we might as well go ahead sooner rather than later. > > o on external power supply on *or* off, should reset touchpad > > Which command? > > > o rotate should probably be done by OHM. > > Totally agree. It's in the best position to enforce policy IMO. It's really something a window manager, in combination with hints should solve. > > > When we are suspended, and the battery wakes us up because it is "low", > > then: > > For now, graceful shutdown after journal has been notified > > How do we notify the journal - OHM is system and the journal is session, no? > > > May do hibernation if enough flash is available. > > Cool. > > > Task: Tune the default DPMS parameters. > > > > Reset keyboard instructions are in trac. > > > > The big question is: how to do idle? > > X DPMS extension? X SS extension? cpuidle kernel patch, about to go > > mainline in Linux, with module to tell ohm the system has been idle? > > other ideas? > > In g-p-m svn I've been using the idletime extension for some time now. > It works well, with a few little quirks, although it only gives the > user-activity point of idle, rather than the machine state idle. Machine state idle is more complex, and may involve detailed knowledge of whether USB devices are installed, for example. Adam Belay's et. al.'s CPUidle work may (part of) be the solution here. There is a patch for 2.6.22, and I think it's now in the -mm tree (or maybe Linus's tree). So we can probably eventually arrange to notify OHM when the system seems to be in a decent state for suspend on idle, and when it is not. - Jim -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power manager specification... (request for comments).
Walter Bender wrote: > Lets please be careful not to over-engineer. While Mike makes good > points, we have this wonderful human social network we can depend upon > as well. E.g., If I am downloading something from your machine, I can > ask you to hold on a second until I finish. Let's take advantage of > the fact that the kids are in the same community/school most of the > time and not worry so much about corner cases until we have some more > breathing room. > Perhaps I was unclear, I was referring to another program *on the same machine* needing the machine to remain active in order to complete a task. That is, things such as: * playing music in the background while you read * downloading a file from the school server which you need for homework while you are reading the assignment/textbook * recording an audio stream while you are taking notes in write (i.e. interviewing someone) * upgrading the OS/downloading updates while you are working in class that is, all single-user on a single-machine use cases. No social networks involved. These are all fairly common use cases. We see the same basic "inhibit_suspend" operation in media-players on Linux or Windows wrt screen savers. You don't want your machine going to sleep in the middle of recording your interview, so the recording activity needs a way to say "hey, I'm working, don't go to sleep right now" (assume we've got a signed activity that can do background record for a moment). I'm not saying that the implementation needs to be there today, I'm just saying that we likely need to eventually move toward an implementation that uses need-based signaling rather than direct manipulation of the whole computer state by any activity. Something as simple as a decorator icon on the home view, (e.g. a bed with a circle-plus-slash over it for western audiences) should be sufficient to let the user know which activity is inhibiting suspension. Hope that's clearer, Mike ... >> On the original topic of the thread (what the power manager should do): >> >>I'm guessing eventually we'll want some of the logic currently in >>the read activity to migrate into HardwareManager. That is, allow >>for signaling "inhibit_suspend( )" and "allow_suspend()"[3], rather >>than directly setting suspend, such that a given activity can >>declare that it must be allowed to continue processing in the >>back-end. Then you'd want something like "suggest_suspend()" so >>that a foreground activity can tell the system "hey, I don't expect >>to do anything for a second or two, if no-one objects, feel free to >>suspend". >> >> From there, a second level does a suggest-suspend from Sugar (or >>whoever) on no-cpu, no-network (other than the autonomous routing), >>no-input, for a given period. No opinion on where/how to put that. >> >>HardwareManager should likely send dbus events so that activities >>can watch for resume, suggested-suspend, or what have you and adjust >>behaviour accordingly. Example usage scenario: switch a per-second >>clock-updating timer to a per-minute timer. >> >> Hope this helps, >> Mike >> >> [1] >> http://dev.laptop.org/git.do?p=projects/read-activity;a=blob;f=readactivity.py;h=3eeb858cc5ea1dc67a60faee90628100479509be;hb=HEAD >> [2] >> http://dev.laptop.org/git.do?p=hardware-manager;a=blob;f=hardwaremanager.py;h=3154b17553621cc41fa947cbff2756372e6e37ec;hb=HEAD >> [3] with allow-suspend happening automatically after a short-ish timeout >> if the activity doesn't re-assert the inhibition >> -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power manager specification... (request for comments).
Hi, On Wed, 2007-08-15 at 16:01 -0400, Jim Gettys wrote: > When we are suspended, and the battery wakes us up because it is > "low", > then: > For now, graceful shutdown after journal has been notified > May do hibernation if enough flash is available. I guess what we want here is to notify to each activity that they should save their state to the datastore. Correct? How much time do we have until the system really shuts off? Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power manager specification... (request for comments).
On 15/08/07, Jim Gettys <[EMAIL PROTECTED]> wrote: > Fpr general comment and discussion, the following is a list of things > cjb and I think should happen. What are we missing? Other opinions? Sorry for getting to the conversation late, it's been a busy week. > Actions that OHM should do: > > o On momentary power button: > turn off screen, suspend machine, leave keyboard and wireless on; > keyboard/touchpad will cause instant on again. Yup. > o On lid close on battery, should turn off keyboard, turn off screen > Then should suspend to RAM, including disabling and > powering down wireless Okay. > o on lid close, on power, leave the machine on and running. Not turn off the backlight? > o On lid open, turn on keyboard, reset keyboard, resume from suspend, > turn wireless back on, tell NM to reassociate (maybe only after some > delay), try previous association first, of course... Sure. > o On ebook mode, should turn off keyboard Turn off as in twiddle some bit to power it down, or just stop the input events? > o On lid open, should reset keyboard > o on ebook to non-ebook mode, should reset keyboard How? > o on external power supply on *or* off, should reset touchpad Which command? > o rotate should probably be done by OHM. Totally agree. It's in the best position to enforce policy IMO. > When we are suspended, and the battery wakes us up because it is "low", > then: > For now, graceful shutdown after journal has been notified How do we notify the journal - OHM is system and the journal is session, no? > May do hibernation if enough flash is available. Cool. > Task: Tune the default DPMS parameters. > > Reset keyboard instructions are in trac. > > The big question is: how to do idle? > X DPMS extension? X SS extension? cpuidle kernel patch, about to go > mainline in Linux, with module to tell ohm the system has been idle? > other ideas? In g-p-m svn I've been using the idletime extension for some time now. It works well, with a few little quirks, although it only gives the user-activity point of idle, rather than the machine state idle. Richard. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power manager specification... (request for comments).
Hello, On 8/17/07, Don Hopkins <[EMAIL PROTECTED]> wrote: > I think just writing the code is a > good antidote to engaging in the arguments in the first place. If the > functionality is straightforward and easy to implement then just do it > rather than argue about it. Hence my suggestion in the parent post about writing some quick shell script to demonstrate/evaluate the feature usefullness in the real life. Personally, I am currently playing with the DCON and other CHI parts, writing ugly scripts to test the added features :-) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power manager specification... (request for comments).
You have to remember that the kids using these machines might not yet know how to read, so just popping up a notice with a paragraph explaining the situation and Yes/No buttons isn't an ideal solution. -Don http://xarg.net/blog/one-entry?entry_id=20005 http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www/db/text/1999/freebsd-hackers/19991003.freebsd-hackers Word of the day: Bikeshedding I saw this word somewhere and did not know what it meant. It turns out to be an excellent word for describing a lot of what goes on in online communities. It comes from Parkinson's Law by C. Northcoate Parkinson. He describes how a planning board will approve spending millions of dollars to build an atomic power plant but if you go to them to get approval to build a bike shed they will argue endlessly. The problem being that the atomic power plant is so large, complex, and difficult to understand that no one can really argue about how exactly it is done. On the other hand, everyone knows what goes into a building a bike shed and so everyone feels qualified to argue about the details. For some reason, technical discussions seem to be particularly susceptible to bikeshedding. There was a great post by Poul-Henning Kamp on the freebsd-hackers list: http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www/db/text/1999/freebsd-hackers/19991003.freebsd-hackers which describes a particularly virulent attack they had on their list and submits a plea to avoid it in the future. I think just writing the code is a good antidote to engaging in the arguments in the first place. If the functionality is straightforward and easy to implement then just do it rather than argue about it. Most of the people spending their time arguing probably have enough inertia that they are not going to write any code and consequently, if you do have the initiative, the code itself is the most suitable response. As Poul-Henning Kamp said: I wish we could reduce the amount of noise in our lists and I wish we could let people build a bike shed every so often, and I don't really care what colour they paint it. Who knows, if you write enough code we might even end up with an atomic power plant (or for you greens in the audience, a lovely old growth forest). http://www.bikeshed.com/ Why Should I Care What Color the Bikeshed Is? "The really, really short answer is that you should not. The somewhat longer answer is that just because you are capable of building a bikeshed does not mean you should stop others from building one just because you do not like the color they plan to paint it. This is a metaphor indicating that you need not argue about every little feature just because you know enough to do so. Some people have commented that the amount of noise generated by a change is inversely proportional to the complexity of the change." Guylhem Aznar wrote: Hello, On 8/17/07, Walter Bender <[EMAIL PROTECTED]> wrote: Lets please be careful not to over-engineer. While Mike makes good points, we have this wonderful human social network we can depend upon as well. E.g., If I am downloading something from your machine, I can ask you to hold on a second until I finish. Let's take advantage of the fact that the kids are in the same community/school most of the time and not worry so much about corner cases until we have some more breathing room. Yet thinking before implementing can easily overcome future problems. I believethe idea of "inibitors" for the various power schemes should not be overlooked since their benefits can be important. In your example, a download activity could make the suspend wait an additional minute or two, explaining the user than its request was noticed, won't happen until the download/upload is over, unless it is overriden. If people are in the same class, of course, but what if the person is several hops away on the mesh network? Moreover, this interesting idea could also be applied to video playback/screen rotation requests, explaining that the screen can't be rotated or the playback will stop, etc. There's a great potential in such examples to go beyond the traditionnal power management done in GNU/linux. But anyway, if you think these cases are so special and supporting them will take too much time, write a quick shell script to test the concepts, play with it, and see if it helps you or if it's just a waste of cpu cycles. PS I have some more suggestions (ex: a maximal suspend mode to carry the machine without using it) but on a computer I don't have here - I will post a message a little bit later. Guylhem ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power manager specification... (request for comments).
Hello, On 8/17/07, Walter Bender <[EMAIL PROTECTED]> wrote: > Lets please be careful not to over-engineer. While Mike makes good > points, we have this wonderful human social network we can depend upon > as well. E.g., If I am downloading something from your machine, I can > ask you to hold on a second until I finish. Let's take advantage of > the fact that the kids are in the same community/school most of the > time and not worry so much about corner cases until we have some more > breathing room. Yet thinking before implementing can easily overcome future problems. I believethe idea of "inibitors" for the various power schemes should not be overlooked since their benefits can be important. In your example, a download activity could make the suspend wait an additional minute or two, explaining the user than its request was noticed, won't happen until the download/upload is over, unless it is overriden. If people are in the same class, of course, but what if the person is several hops away on the mesh network? Moreover, this interesting idea could also be applied to video playback/screen rotation requests, explaining that the screen can't be rotated or the playback will stop, etc. There's a great potential in such examples to go beyond the traditionnal power management done in GNU/linux. But anyway, if you think these cases are so special and supporting them will take too much time, write a quick shell script to test the concepts, play with it, and see if it helps you or if it's just a waste of cpu cycles. PS I have some more suggestions (ex: a maximal suspend mode to carry the machine without using it) but on a computer I don't have here - I will post a message a little bit later. Guylhem ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power manager specification... (request for comments).
Lets please be careful not to over-engineer. While Mike makes good points, we have this wonderful human social network we can depend upon as well. E.g., If I am downloading something from your machine, I can ask you to hold on a second until I finish. Let's take advantage of the fact that the kids are in the same community/school most of the time and not worry so much about corner cases until we have some more breathing room. -walter On 8/16/07, Mike C. Fletcher <[EMAIL PROTECTED]> wrote: > Jim Gettys wrote: > ... > >> There seems to be no way to manually adjust the backlight level in > >> ebook mode. What would be the policy for it? Leave it on all the time > >> or dim down after some idle time? Also CPU (and wireless?) should go > >> to suspend for most of time in ebook mode? > >> > > > > We have code in at least our PDF viewer to literally do exactly this; as > > soon as the page is rendered and it is idle, it puts the machine to > > sleep. > > > For the activity developers in the audience: > >This is (I believe) in the GIT read-activity/readactivity.py[1] >module. The implementation uses the HardwareManager[2] service >(set_kernel_suspend) exposed over dbus to directly send the kernel >into suspended state. AFAICS there's no allowance for tracking >whether something *else* might need the machine to be alive (e.g. a >download or the like being done in the background). The same >Manager object has controls for various operations such as changing >brightness and the like. > > On the original topic of the thread (what the power manager should do): > >I'm guessing eventually we'll want some of the logic currently in >the read activity to migrate into HardwareManager. That is, allow >for signaling "inhibit_suspend( )" and "allow_suspend()"[3], rather >than directly setting suspend, such that a given activity can >declare that it must be allowed to continue processing in the >back-end. Then you'd want something like "suggest_suspend()" so >that a foreground activity can tell the system "hey, I don't expect >to do anything for a second or two, if no-one objects, feel free to >suspend". > > From there, a second level does a suggest-suspend from Sugar (or >whoever) on no-cpu, no-network (other than the autonomous routing), >no-input, for a given period. No opinion on where/how to put that. > >HardwareManager should likely send dbus events so that activities >can watch for resume, suggested-suspend, or what have you and adjust >behaviour accordingly. Example usage scenario: switch a per-second >clock-updating timer to a per-minute timer. > > Hope this helps, > Mike > > [1] > http://dev.laptop.org/git.do?p=projects/read-activity;a=blob;f=readactivity.py;h=3eeb858cc5ea1dc67a60faee90628100479509be;hb=HEAD > [2] > http://dev.laptop.org/git.do?p=hardware-manager;a=blob;f=hardwaremanager.py;h=3154b17553621cc41fa947cbff2756372e6e37ec;hb=HEAD > [3] with allow-suspend happening automatically after a short-ish timeout > if the activity doesn't re-assert the inhibition > > -- > > Mike C. Fletcher > Designer, VR Plumber, Coder > http://www.vrplumber.com > http://blog.vrplumber.com > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > -- Walter Bender One Laptop per Child http://laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power manager specification... (request for comments).
Jim Gettys wrote: ... >> There seems to be no way to manually adjust the backlight level in >> ebook mode. What would be the policy for it? Leave it on all the time >> or dim down after some idle time? Also CPU (and wireless?) should go >> to suspend for most of time in ebook mode? >> > > We have code in at least our PDF viewer to literally do exactly this; as > soon as the page is rendered and it is idle, it puts the machine to > sleep. > For the activity developers in the audience: This is (I believe) in the GIT read-activity/readactivity.py[1] module. The implementation uses the HardwareManager[2] service (set_kernel_suspend) exposed over dbus to directly send the kernel into suspended state. AFAICS there's no allowance for tracking whether something *else* might need the machine to be alive (e.g. a download or the like being done in the background). The same Manager object has controls for various operations such as changing brightness and the like. On the original topic of the thread (what the power manager should do): I'm guessing eventually we'll want some of the logic currently in the read activity to migrate into HardwareManager. That is, allow for signaling "inhibit_suspend( )" and "allow_suspend()"[3], rather than directly setting suspend, such that a given activity can declare that it must be allowed to continue processing in the back-end. Then you'd want something like "suggest_suspend()" so that a foreground activity can tell the system "hey, I don't expect to do anything for a second or two, if no-one objects, feel free to suspend". From there, a second level does a suggest-suspend from Sugar (or whoever) on no-cpu, no-network (other than the autonomous routing), no-input, for a given period. No opinion on where/how to put that. HardwareManager should likely send dbus events so that activities can watch for resume, suggested-suspend, or what have you and adjust behaviour accordingly. Example usage scenario: switch a per-second clock-updating timer to a per-minute timer. Hope this helps, Mike [1] http://dev.laptop.org/git.do?p=projects/read-activity;a=blob;f=readactivity.py;h=3eeb858cc5ea1dc67a60faee90628100479509be;hb=HEAD [2] http://dev.laptop.org/git.do?p=hardware-manager;a=blob;f=hardwaremanager.py;h=3154b17553621cc41fa947cbff2756372e6e37ec;hb=HEAD [3] with allow-suspend happening automatically after a short-ish timeout if the activity doesn't re-assert the inhibition -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power manager specification... (request for comments).
On Thu, 2007-08-16 at 07:23 +0800, Yuan Chao wrote: > > > o On momentary power button: > > turn off screen, suspend machine, leave keyboard and wireless on; > > keyboard/touchpad will cause instant on again. > I'm curious here that I thought the wireless needs CPU to work with. > Why suspend the machine and leave the wireless on? No, our wireless is able to forward packets in the mesh network without the main CPU being powered. It is important for people to easily leave their machine in a mode which maintains the mesh network for others in the network. > > > o on lid close, on power, leave the machine on and running. > Even though it's on AC power, maybe the screen can also be turned off > to be more Eco? Yup. It certainly should be. > > > o On ebook mode, should turn off keyboard > > o On lid open, should reset keyboard > There seems to be no way to manually adjust the backlight level in > ebook mode. What would be the policy for it? Leave it on all the time > or dim down after some idle time? Also CPU (and wireless?) should go > to suspend for most of time in ebook mode? We have code in at least our PDF viewer to literally do exactly this; as soon as the page is rendered and it is idle, it puts the machine to sleep. > > > o rotate should probably be done by OHM. > There seems no way to predict which direction to go in ebook mode as > no position sensor. Here you mean restore the rotation after get back > from ebook mode? No, mostly that we happened to first implement this in Sugar, and it is really much more a hardware and window manager function from a architectural perspective. - Jim -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power manager specification... (request for comments).
On 8/16/07, Jim Gettys <[EMAIL PROTECTED]> wrote: > Fpr general comment and discussion, the following is a list of things > cjb and I think should happen. What are we missing? Other opinions? I'm not an expert here, but I'd like to share some ideas. How about sorting these events into catagories like "on AC power", "on battery"? Though XO doesn't use ACPI as most recent notebook PCs do, we can still refer to some existing ACPI scripts as most events are in common. > o On momentary power button: > turn off screen, suspend machine, leave keyboard and wireless on; > keyboard/touchpad will cause instant on again. I'm curious here that I thought the wireless needs CPU to work with. Why suspend the machine and leave the wireless on? > o on lid close, on power, leave the machine on and running. Even though it's on AC power, maybe the screen can also be turned off to be more Eco? > o On ebook mode, should turn off keyboard > o On lid open, should reset keyboard There seems to be no way to manually adjust the backlight level in ebook mode. What would be the policy for it? Leave it on all the time or dim down after some idle time? Also CPU (and wireless?) should go to suspend for most of time in ebook mode? > o rotate should probably be done by OHM. There seems no way to predict which direction to go in ebook mode as no position sensor. Here you mean restore the rotation after get back from ebook mode? -- Best regards, Yuan Chao ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power manager specification... (request for comments).
On Wed, Aug 15, 2007 at 04:01:47PM -0400, Jim Gettys wrote: > Fpr general comment and discussion, the following is a list of things > cjb and I think should happen. What are we missing? Other opinions? > > Actions that OHM should do: > > o On momentary power button: > turn off screen, suspend machine, leave keyboard and wireless on; > keyboard/touchpad will cause instant on again. > o On lid close on battery, should turn off keyboard, turn off screen > Then should suspend to RAM, including disabling and > powering down wireless > o on lid close, on power, leave the machine on and running. > o On lid open, turn on keyboard, reset keyboard, resume from suspend, > turn wireless back on, tell NM to reassociate (maybe only after some > delay), try previous association first, of course... > o On ebook mode, should turn off keyboard > o On lid open, should reset keyboard > o on ebook to non-ebook mode, should reset keyboard > o on external power supply on *or* off, should reset touchpad On external power supply off, should check lid, if lid is closed then we should do the 'lid close on battery' process. Possibly, on external power supply on, we should switch to 'lid close, on power' state. > o rotate should probably be done by OHM. > > When we are suspended, and the battery wakes us up because it is "low", > then: > For now, graceful shutdown after journal has been notified > May do hibernation if enough flash is available. > > Task: Tune the default DPMS parameters. > > Reset keyboard instructions are in trac. > > The big question is: how to do idle? > X DPMS extension? X SS extension? cpuidle kernel patch, about to go > mainline in Linux, with module to tell ohm the system has been idle? > other ideas? -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. signature.asc Description: Digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Power manager specification... (request for comments).
Fpr general comment and discussion, the following is a list of things cjb and I think should happen. What are we missing? Other opinions? Actions that OHM should do: o On momentary power button: turn off screen, suspend machine, leave keyboard and wireless on; keyboard/touchpad will cause instant on again. o On lid close on battery, should turn off keyboard, turn off screen Then should suspend to RAM, including disabling and powering down wireless o on lid close, on power, leave the machine on and running. o On lid open, turn on keyboard, reset keyboard, resume from suspend, turn wireless back on, tell NM to reassociate (maybe only after some delay), try previous association first, of course... o On ebook mode, should turn off keyboard o On lid open, should reset keyboard o on ebook to non-ebook mode, should reset keyboard o on external power supply on *or* off, should reset touchpad o rotate should probably be done by OHM. When we are suspended, and the battery wakes us up because it is "low", then: For now, graceful shutdown after journal has been notified May do hibernation if enough flash is available. Task: Tune the default DPMS parameters. Reset keyboard instructions are in trac. The big question is: how to do idle? X DPMS extension? X SS extension? cpuidle kernel patch, about to go mainline in Linux, with module to tell ohm the system has been idle? other ideas? -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
