GNOME Bugzilla – Bug 560085
SuspendHybrid support missing in gnome-power-manager
Last modified: 2012-03-23 09:34:41 UTC
Please describe the problem: Running Xubuntu Intrepid with uswsusp I noticed that there is no support for SuspendHybrid in g-p-m. Hybrid suspend means that the machine's state is put into the RAM and written to a swap disk and then is suspended. If there is still some battery left you can resume from RAM. Otherwise you can resume from the swap disk during the next boot. I consider this very useful. There's support for this in HAL via the 'SuspendHybrid' method: $ lshal|grep SuspendHybrid org.freedesktop.Hal.Device.SystemPowerManagement.method_names = {'Suspend', 'SuspendHybrid', 'Hibernate', 'Shutdown', 'Reboot', 'SetPowerSave'} (string list) $ lshal|grep suspend-hybrid org.freedesktop.Hal.Device.SystemPowerManagement.method_execpaths = {'hal-system-power-suspend', 'hal-system-power-suspend-hybrid', 'hal-system-power-hibernate', 'hal-system-power-shutdown', 'hal-system-power-reboot', 'hal-system-power-set-power-save'} (string list) Is there any chance to get this implemented in g-p-m? I could probably cook up a patch for this. Steps to reproduce: 1. Start g-p-m 2. Open the settings dialog 3. Left-click the tray icon Actual results: There are no SuspendHybrid options in the settings dialog and the tray icon menu. Expected results: There are SuspendHybrid options in the settings dialog and the tray icon menu. Does this happen every time? Yes Other information:
Hi, Can I suggest if this patch is created, that SuspendHybrid is implemented as an option for HOW suspend is done, not an entire new operation. For the sake of argument I'm imagining a checkbox in the GUI called "also save to disk during suspend in case of power loss". If ticked then a suspend will trigger SuspendHybrid instead. For any non-techie user who looks into the difference, SuspendHybrid is going to be viewed as a "more sensible" version of suspend: it takes longer to suspend, but means there's no need to worry if the battery drains. The other benefit is DBUS APIs for suspend stay the same: apps using the APIs get the benefit of your change instantly.
A hybrid suspend isn't just a "better" suspend. It takes longer, and uses up far more power than a normal hibernate. I'm not sure I see a use case for it's use.
(In reply to comment #2) > A hybrid suspend isn't just a "better" suspend. That's exactly the point. It's not just about suspending. > I'm not sure I see a use case for it's use. Hybrid suspend comes into play when there's a risk that your laptop battery runs out while it is suspended. This could be due to too much shaking (I've had that when I had it in my backpack while cycling to work) or simply due to low battery. It allows you to fall back to hibernate behaviour whenever something weird happens in suspend, without having to resume first and then go into hibernate (which I guess some systems do on low battery). Personally, I find it kinda neat and I thought others might be interested in having this supported as well. For me it's worth the extra CPU cycles.
I would love to have this - it would have saved me and my girlfriend a lot of trouble already. It's very common for us to put our laptops to sleep and leave them like that for a couple days just to find the battery ran out and we lost our session/work.
The kernel needs to provide this first. Last time I checked, the only way to get a hybrid suspend was with a kernel patchset like tux-on-ice.
Having uswsusp installed with s2both is enough to have hybrid suspend, according to man pm-suspend-hybrid