After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 637473 - power: On battery, suspend by default, not hibernate
power: On battery, suspend by default, not hibernate
Status: RESOLVED FIXED
Product: gnome-power-manager
Classification: Deprecated
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: GNOME Power Manager Maintainer(s)
GNOME Power Manager Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2010-12-17 15:45 UTC by Colin Walters
Modified: 2010-12-17 16:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
power: On battery, suspend by default, not hibernate (1.25 KB, patch)
2010-12-17 15:45 UTC, Colin Walters
none Details | Review

Description Colin Walters 2010-12-17 15:45:39 UTC
I can't think of a conceivable rationale for hibernate being the
default on battery power.
Comment 1 Colin Walters 2010-12-17 15:45:41 UTC
Created attachment 176596 [details] [review]
power: On battery, suspend by default, not hibernate
Comment 2 Bastien Nocera 2010-12-17 15:57:38 UTC
Hughsie will handle that. IMO, we shouldn't need to change this, the top-end should be clever enough to fallback to suspend instead.
Comment 3 Colin Walters 2010-12-17 16:14:17 UTC
(In reply to comment #2)
> Hughsie will handle that. IMO, we shouldn't need to change this, the top-end
> should be clever enough to fallback to suspend instead.

That's not the point - if the system can both hibernate and suspend, do we *really* want to hibernate?

As far as the fallback, I can understand falling back to hibernate if we can't suspend, but suspend doesn't strike me as a fallback for hibernate.
Comment 4 Colin Walters 2010-12-17 16:38:23 UTC
<hughsie_> walters: no, not really. if you suspend on battery you could loose data if the battery runs out
<mjg59> hughsie_: We should just handle that case better. Hibernate as the default on battery isn't sane.
<mjg59> It adds huge quantities to latency
<mjg59> Hibernate on critical is sensible, and any modern hardware will automatically resume when it's critical
<hughsie_> walters: in an ideal world, we would resume when low power, then hibernate, but that's assuming hardware that works
<hughsie_> mjg59: it does?
<mjg59> hughsie_: Basically, yes
 hughsie_: There's a low power wakeup line on all Intel chipsets since 2004 at least
<hughsie_> mjg59: automatically, with an acpi event, or do we have to setup the wakeup?
<mjg59> Automatically
<hughsie_> do we know why we resumed?
<mjg59> hughsie_: Well, we'll know that the battery is critical
<hughsie_> mjg59: true, but we don't know if the user just opened up the lid, either
<hughsie_> true
<mjg59> hughsie_: Well, if the default critical action is set to hibernate, then we're good
 mizmo: http://www.codon.org.uk/~mjg59/tmp/hotdog_efi_alpha.jpg
<mjg59> hughsie_: If the user opens the lid and we realise that we're critical then the right thing to do is to hibernate anyway
<drago01> hibernate should be the last resort only
 like when battery is critical
 otherwise it sucks
<walters> also, the OS and apps need to be fixed to not lose data anyways
<hughsie_> walters: okay, point taen
<mjg59> Ah, ok. It works pretty slicky - put in the USB key in the startup manager and the logo shows up
<hughsie_> walters: if you add a big descriptive note to the xml discussing what we've added here, you can commit your patch
<walters> hughsie_: a link to the bug maybe?
<hughsie_> on the assumption that mjg is right about autoresume when critical