Feature roadmap/Improved battery life

Feature subcategory		Is part of::Category:Power management
Requesters		{{#arraymap:Kim, Carla, Gnu, Ethiopia, 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. 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.
Specification		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>7958</trac> DCON flicker on resume (kernel regression; perhaps Deepak, Andres, Mitch, or Adam Jackson?) 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. 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, Mitch, Deepak|,|x|Contact person::User:x}}
Priority		Priority::1
Helps deployability?		Helps deployability::yes
Target for 9.1?		Target for 9.1::yes