Feature roadmap/Improved battery life

Feature subcategory		Is part of::Category:Power management
Requesters		{{#arraymap:User:Kimquirk, User:Carla, User:Gnu, Ethiopia, User:Juliano|,|x|Requested by::x}}
Requirements		Background information: a list of UI actions which may affect power usage: Requirements#Power Management Requirements Our job is to increase battery life in as many modes as possible. For a test plan for these features written back at the 703 release, see Tests/Suspend_Resume. Power save (here after called idle suspend) should default on but the user also the option to not use it. When you turn the radio off the in the network control panel it must cut off all power to the wireless chip. Must rewrite the documentation on power and explain it to Frances so that she understands how to use it. (add link to existing documentation). Should offer a full featured set of power options in GUI. Not critical but nice to have. Idle suspend must dim the screen after 1 minute of the user not touching the keyboard or touchpad. Then after an additional 2 minutes it must change the screen completely off. Must allow setting of those values in the control panel. The only exceptions are that when the audio device is playing, when olpc-update is running. Must turn the screen back on in less than 1 second after the user touches the keyboard or touchpad. Idle suspend must turn the CPU off. Must allow activities to override the idle suspend mode above. That is to not suspend even if the time has passed. Must not lose your network connection, activity state, sugar GUI elements and collaboration (e.g. start a chat, let the XO suspsend then otehr chat person chats, that new chat text should show on the suspended XO without turning on the screen) after waking from idle suspend. Must not crash. Multicast, ARP, mDNS, the Presence Service, and collaboration must all work in the presence of autosuspend. Should not turn the screen on unless the user interacts with the keyboard. Wireless chip must respond to ARP requests when in Idle Suspend mode. Screen must not flicker on resume. Should allow users to disable the mesh: reduces power consumption of the WiFi chip, allows the WiFi chip to enter power-save mode, and most importantly, allows lid-closed suspend to totally power off the WiFi chip. <trac>6955</trac> Should put the EC into deep sleep when in a lid-closed suspend. This will cut its power from about 60ma to about 20ma (check with rsmith), which would further increase the duration of a lid-closed suspend before the battery drains. (* not likely to make 9.1 with current resources *) Should improve cpu idle detection. Currently we can't auto-suspend very often (only after >1 minute of no user interaction) because suspend is so heavy-handed. The cpuidle infrastructure in the kernel should be able to tell us when it's safe to suspend because no process wants access to the CPU for the next few seconds. Most of the pieces are there. "Lid close" behavior will be unchanged from the 8.2.0 release; on closing the lid, the screen and wifi (if connected to an access point) should turn off, and should turn themselves back on when the lid is reopened. There should be a way to enter the "lid close" sleep above using the power button; exact details are with User:pgf, who is working on the quick-power-button-press menu.
Specification		Requirement 2 addressed by: <trac>9145</trac> -- Disabling the radio in control panel should power-down WiFi chip <trac>8948</trac> -- "Turn off the wireless radio" checkbox is confusing <trac>8424</trac> -- Sugar control panel's Network > Wireless Radio checkbox does nothing if Power > Extreme power management checked <trac>8062</trac> -- Need a default to leave RF turned off on reboot (8062 reminds us that as we evolve the power settings, there needs to remain one that keeps the radio off and survives reboots.) <trac>7047</trac> -- Suspend turns radio on even if it was forced off <trac>6995</trac> -- Mesh icon in Frame should allow Mesh to be turned off (If mesh is off and access point is off -- and we don't support ad-hoc mode -- then the radio should be powered down, too. This would mean our interface was so intuitive that it didn't need a control-panel item to turn off the radio.) Requirement 3 possibly addressed by edits to existing documentation here: http://wiki.laptop.org/go/Feature_Longer_battery_life and here: http://wiki.laptop.org/go/Suspend_and_resume Requirement 4 addressed by: <trac>2765</trac> -- Need to turn off DCON after some time in idle suspend <trac>4606</trac> Requirement 5 addressed by: <trac>9054</trac> -- Speed up USB resume (kernel) <trac>7981</trac> -- EC mask setting is inefficient <trac>8916</trac> -- Extreme Power Management doesn't unload USB for fast resumes <trac>7384</trac> -- Manually enabled USB-disabling Power Management Requirement 9 addressed by: <trac>6818</trac> -- Make the multicast wakeup filter work with collaboration (Ricardo Carrano?) <trac>7458</trac> -- Intermittent lockup on WOL Requirement 11 addressed by: <trac>3732</trac> -- ARP broadcasts don't wake auto-suspended laptops Requirement 12 addressed by: <trac>8893</trac> -- DCON flicker on resume (kernel regression; perhaps Deepak, Andres, Mitch, or Adam Jackson?) <trac>7958</trac> -- DCON shows totally wrong image during suspend, with lots of colored noise. (Seems rare, whereas #8893 is 100% reliable, so we should go for #8893 first and get to #7953 if it still exists and we have time.) Other: <trac>9055</trac> -- Create 9.1 test plans for automatic power management There's still a major Python bug that causes multi-threaded pyGTK2 programs to poll uselessly once a second (<trac>4680</trac>, <trac>4677</trac>). Much work was done to close it, but there is still a small sprint required to get it done. This not only reduces power use directly, but also allows the system to suspend because it doesn't appear that activities need to do some work soon. We have a bug if we enter suspend while audio is playing: <trac>6201</trac>. This should be fixed either with the correct kernel fix, or by refusing to suspend while the audio device is open. Background on power draw including a break down watts used in different modes: XO Power Draw#The Numbers Per-Activity Power Usage Significant technical actions (as suggested by John/Gnu) that could reduce the laptop's power draw: not to Greg - move to collaboration. Reduce packet traffic during sharing -- particularly multicast traffic, which loads many machines (and wakes them up from autosuspend). This will require diagnosis and improvement of the presence and collaboration protocols. Some work was done on this, after the high packet traffic melted the WiFi bandwidth in early deployments (e.g. turn on 30 laptops in the mesh, none of them can usefully get anything done), but our main response was to tell later deployments "Don't use the mesh, use access points" -- a significant reversal that we should keep working to fix. Owners for each subrequirement as follows: Requirements 1 - 5, 7, 8, 10, owned by CJB. 6 by CJB, 9 and 11 networking team (Ricardo?), 12 Mitch and Deepak Product manger Greg, QA Joe.
Owners		{{#arraymap:Joe, Gregorio, Cjb, Wmb@firmworks.com, Deepak|,|x|Contact person::User:x}}
Priority		Priority::1
Helps deployability?		Helps deployability::yes
Target for 9.1?		Target for 9.1::yes