----- Original Message -----
On Sun, Sep 27, 2015 at 7:42 PM, kendell clark
<coffeekingms(a)gmail.com>
wrote:
> You should definitely be able to change the autosuspend settings. Just
> press enter on the item and a menu should appear with buttons.
I can, it's just that there's an incongruence among the default
setting (off), the notification I get (it will hibernate), and what
actually happens (sleep/suspend to RAM).
Then there's a bug in UPower or systemd.
For a 1% battery state to result in anything other than power off or
hibernate (suspend to disk) seems like a bad idea.
Hibernate is the default if it's supported. You can check with:
upower -d | grep critical-action
And since
hibernation is variably broken, that's probably not a good option.
https://bugzilla.redhat.com/show_bug.cgi?id=1206912
Like I mention in the bug, hibernation depends significantly on the
firmware on today's hardware. But on Linux it depends on booting
normally, and the kernel discovering the hibernation image, but I've
never seen this work on any EFI Mac systems I've tried this on: the
kernel claims to look for a hibernation image but doesn't find it.
This happens whether resume= is set on the kernel command line or not.
On BIOS it resumes only if resume= is on the kernel command line even
though this supposedly is handled by initramfs, but anaconda doesn't
include any hibernation support (neither the resume= nor does it
create a sufficiently large swap partition).
And then there are the IRST supporting laptops, and while there's some
kernel support for this I don't know if systemd or GNOME will leverage
it. The RAM to disk dump is definitely always unencrypted though.
Nobody added support for IRST as a new kernel sleep state, so the support
in systemd isn't finished.
*BUT*. Suspending on a machine which supports that mode should be migrated
to disk by the firmware. Right now, given the kernel's support for IRST,
we can't show the difference between a firmware hibernation and suspend.
Cheers