Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.
Launchpad Entry: power-management-settings
Packages affected: gnome-power, pm-utils, hal, hwtest
Summary
With power management getting better at the kernel and driver level we can start to rethink how power management can be presented to the user, and what reasonable defaults are. Considering the large number of Ubuntu users, we'd like to start moving to more aggressive power saving defaults to save energy.
Release Note
New with this version of Ubuntu, the default settings for power management now include suspend by default on systems that are known to have working power management. Also we are updating the suspend feature to allow for a configurable time at which the computer will switch from suspend to hibernate automatically.
Rationale
Saving power is a good thing. Many users don't use power management features because those features are poorly implemented, or they don't think to turn them on. If we turn them on by default we can hopefully save a little bit of electricity on lots of computers.
Use Cases
- A user checks e-mail and then goes to bed. The computer should sleep while the user is sleeping.
- A user checks e-mail, goes to bed, and then realizes that there is another e-mail to write. We need to have a timeout such that it's likely the computer will be ready to use when waking up.
- A user puts the computer to sleep on battery, but then forgets about it. The computer should then go into a deeper power save state like hibernate.
Design
We will start using the power management functionality that we have by setting the defaults to start using it. This will only be done with machines that currently have whitelisted FDI files in the system. While this is likely to be less than the number of machines that could benefit from these improvements, it creates a starting point for enabling functionality. It is likely that all machines shipped and certified with any major Linux distributor will be appropriately whitelisted, so this segment of machines is expected to grow significantly over time.
Implementation
- Add to GNOME Power Manager (GPM) the ability to distinguish between those on the whitelist and not. Adjust defaults appropriately. Need to distinguish between user settings and whether they are the defaults. If on whitelist the machine should suspend by default after timeout.
- Adjust GPM settings to dim screen on both battery and AC by default
- Add the ability to pm-utils to distinguish why the system was woken up from sleep. If it was from timer, pm-utils should put the machine back into hibernate.
- PM utils will need to read the timeout value from the HAL suspend command and set a timer to wake up from suspend after the specified amount of time.
- Adjust GPM so that when it calls the HAL suspend command it passes the number of seconds that suspend will happen before hibernate.
- Integrate GPM and GNOME Session Manager such that documents that are unsaved can be saved in temporary locations to reduce risk of data loss.
- GPM Must make a loud noise if the lid is closed, it's asked to suspend/hibernate on that action, and is unable to.
- Build a command line inhibit utility for CLI applications to use
- Add inhibit feature to Firefox download manager
- Add inhibit feature to Transmission
- Add inhibit feature to printing so that long print jobs don't get broken by the comptuer sleeping (it is particularly annoying that Mac OS X doesn't do this)
- Build notification application to explain to the user what is causing their session to be inhibited.
- Disable de-bouncing in GPM and allow all events to process.
- Disable hibernation if a kernel upgrade has occurred.
- Modify GPM inhibit logic so that inhibit is only inhibiting the actions that are automatic, not user generated actions.
- Add question to HW Test so that it asks users about suspend/resume to create a larger whitelist database
Determining Whitelist
The whitelist will be determined by looking at HAL, specifically the properties on org.freedesktop.Hal.devices.computer. If there are any properties that include "power_management.quirk" in their name we will include the machine on the whitelist. This includes "power_management.quirk.none" which we will assume that if it's set, someone has done this intentionally.
Issues
- How do we display to the user whether they are on the whitelist or not? How do we tell them how to change this?
- Does the whitelist just come from the machine, or does it include all drivers? For example if someone puts in a PCMCIA card that can't suspend.
How do we handle things like cron-daily? Should we wake up to run them in the middle of the night? How should this be handled in PM Utils? (is this a server-only issue?)
Wake-on-LAN was a requested feature in the session, but that doesn't seem like something we have a way to configure today. Do we need a tool for this? Where should it go in other tools. (is this a server-only issue?)
Migration
User settings will not be migrated, and will be kept how the user has set them previously. There will be no migration.
Test/Demo Plan
We can test many of these as unit tests, and that shouldn't effect the other parts of the system. But, the most important testing will be getting this into Ibex as soon as possible to allow a wide amount of testing on a variety of machines.
Comments
I spoke with MatthewGarret regarding trying to do more advanced whitelisting, specifically by device. He doesn't know of anyway to reliablly do this, and thinks that the only thing that might work is to check for "all Intel" but even that could be borked by laptop manufacturers. --TedGould
Whitelisting/Blacklisting by device+driver will be necessary for bad-designed notebooks such as my Samsung P35 (04K), which can resume only IFF radeonfb is loaded in addition to the free Xorg radeon driver. --NikolausFilus