Simplifying system sleep functions
Currently Ubuntu contains two separate sleep functions, suspend and hibernate. This choice confuses users and is a un-necessary complication to 'sleeping' the computer. The proposed change is to combine both 'suspend' and 'hibernate' into a single 'sleep' function. When the user presses 'sleep', the computer should both suspend and hibernate simultaneously. The computer remains suspended for a set period of time (e.g. 30min) or until the battery charge falls below a set level. At the point the suspend state is discarded, and if the user wakes the computer after this point their state is restored from hibernate. However if the user wakes the computer before the suspend state is discarded, the computer is restored from 'suspend' and the 'hibernate' state is discarded.
Blueprint information
- Status:
- Complete
- Approver:
- Martin Pitt
- Priority:
- Low
- Drafter:
- John Lea
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
- Martin Pitt
Whiteboard
pitti, 2011-05-23: John, can you please add the resulting work items here and set to "review"? (This should be enough for drafting, I don't think we'll need a full spec page). Thanks!
Adam Porter, 2011-05-26: I just want to mention that this may not be a good idea for a default behavior. My Dell XPS M1330 laptop seems to suspend and resume reliably with Natty, and seemed to with Maverick as well, but I'm not confident enough that I'd want it turning itself on in my bag to discard the suspend state and hibernate. It only takes one edge-case bug to happen one time to bake a laptop in a bag, leaving a drained battery at best, or bricking a laptop at worst. I think the kernel and drivers (consider binary blobs, too) need to be more robust in their handling of suspend/resume before this should even be considered for default behavior.
John Lea, 2011-05-27: Adam, thanks for your comment. The suggestion in the description is for suspend and hibernate to happen at the same time, and then one of the states would be discarded depending on how long the user waits to resume, so what you describe would not be a issue. However due to the quality issues with both suspend and hibernate it has been decided to fix suspend first and then fix hibernate before implementing this change.
John Lea, 2011-05-27: The resulting work items are:
- Remove hibernate function due to it's instability and lack of quality
- Focus all efforts on fixing the issues with the suspend function
- Find way to estimate the length of time the computer can remain in suspend before battery is depleted. This information will be displayed to the user if they select the suspend function from the device indicator.
- Identify and fix the issues that cause the suspend function to fail to un-suspend the computer on a number of systems.
- Investigate the causes of power consumption while a computer is in the suspend state, and work to reduce this power consumption where possible
pitti, 2011-05-27:
- seems your text was cut off at the end?
- we already removed hibernate last cycle for a while, and got pushback from both users and OEM. It does work for a lot of people, and we don't want to just break it without having a better replacement.
- It seems before we can actually address that in the UI, there's a lot of infrastructure/
- "Focus all efforts on fixing the issues with the suspend function" -> was there anything concrete that's broken with it? it's not a very actionable work item (similar to the next one); these tend to be highly hardware specific, and should be reported and handled in bugs, not as general work items
- Similar with devices which draw a lot of power in suspend -> hw specific, and handle as bugs
I untarget it for desktop/oneiric for now, as right now there is not really anything actionable for the desktop team here.
John Lea, 2011-05-27:
Hi Pitti, in response to your points:
- Hibernate is in such a bad state it does not meet the current 'consumer standard' quality requirements for Ubuntu. If we want hibernate to remain in Ubuntu we needs to work reliably; in the straw poll during UDS it simply failed to work on a significant percentage of attendees computers. The other issue brought up in the UDS session is that when it does work it takes an inordinate amount of time, and some computers auto-hibernate automatically by default, potentially frying the computer if it is in a bag. Until these issues are solved it will not be suitable for inclusion. A highly visible feature like this must either work for all users or fail gracefully (e.g. we know when it is not going to work and we manage the user experience).
- Suspend is also in a bad state, and has a high incidence of simply not working on a good percentage of computers (again as discovered at UDS). If we have limited engineering resources it makes more sense to devote them to fixing suspend before moving on to fixing hibernate.
- The removal of hibernate is temporary, when we get it working it will be re-included.
- The issues with suspend are:
* A good percentage of computers can enter the suspend state but cannot then un-suspend, forcing a power cycle. This was discovered at UDS as some participants in this session demonstrated suspend not working on their computers. If we are seeing failure in this small sample size, it is inevitable the problem is more widespread.
* On some computers suspend has abnormally high power consumption, only lasting 30min or less until the battery is depleted!
* Due to fact that it will have hard to solve the above problem for all hardware combinations, we need a way to message to the user how long suspend is going to last until the battery is depleted and the user looses their data.
- So given these issues, we should investigate the causes of suspend not working, try to solve them, and also find a way of learning if suspend does not work on a specific system so we can disable the option on system where it does not work. We also need to find a way to measure and then estimate battery usage in suspend, so this can be signalled to the user. And also try to investigate the bugs that cause high power consumption.
These fixes will bring suspend up to the 'consumer standard' that we are targeting with 11.10.
pitti, 2011-05-30:
- The only time where the computer auto-hibernates right now by default is when it's running and the battery gets dangerously low. But if you put your computer in a bag while it's running, then the damage is already done. The "computer in bag" problem will happen if we would do a thing like waking up automatically from suspend to do a hibernation, which is why this approach was vetoed.
- I don't personally mind disabling hibernation by default, but I'd like to see the OEM team's signoff for this (Tony?)
- We won't disable suspend by default for everyone. It's an incredibly useful feature, and has worked reliably on the majority of machines for years these days. We can certainly disable it on machines where it's known-broken, and we can't/don't know how to fix it. We need bug reports for this.
- Bugs with resume failure or high power usage during suspend are kernel space (so not appropriate for the desktop track), and also should be handled as bugs, not blueprint (they can't be generalized, they are highly hardware specific and often due to buggy BIOSes, etc.)
- The one thing that is desktop specific here is to add a time estimation to gnome-power-manager and add it to the indicator menu. How should that look like, something like "Suspend (will last 5:30 hours)"?
-
