Bug 399727

This is separate from hybrid-sleep I presume?

(In reply to Kai Uwe Broulik from comment #1)
> This is separate from hybrid-sleep I presume?

Yes. If I understood well, hybrid-sleep means that a suspend action is performed, with an additional save to disk of the ram content (as if we hibernated). Meaning that if the power goes off (or the battery deplete in the case of a laptop), the memory content will still be available on reboot (transforming suspend into hibernate). 

In the case of laptops without S3, that means that the battery will be depleted as with suspend, which is avoided with suspend-then-hibernate.

Okay, sounds interesting. Perhaps the best approach would be to have a setting in PowerDevil where you can configure "[x] Automatically hibernate when suspended for [n minutes]" if supported. I didn't find a DBus interface to change the time, so this must perhaps be done by the user explicitly, but I can surely check for being supported and trigger it.

Thanks for your answers. 
I like your idea of ux, as this is something to configure in addition to current powerdevil settings.

I don't know much about DBus. In a systemd way, the delay is set in a config file (see Description).

I would be glad to report to DBus if appropriate but I really have no idea on how to do it. The function is quite recent and comes with systemd 239, so that might explain the lack of interface.

If there is anything I can do to help on this issue, please tell me :)

*** Bug 400615 has been marked as a duplicate of this bug. ***

Currently you can use a workaround:
ln -s /usr/lib/systemd/system/systemd-suspend-then-hibernate.service /etc/systemd/system/systemd-suspend.service
as the powerdevil operates suspend correctly.

Not sure if this adds anything meaningful to the discussion but I have been getting around this by setting /sys/power/mem_sleep to 'deep' instead of 's2idle' on my Dell XPS 15 9570. This allows for an actual sleep state. The only issue I have encountered is occasionally the pstate of the processor gets stuck at maximum so instead of the normal 800MHz idle state they cores all remain at 3800+ MHz and the only way to fix it is to reboot.

Git commit daa06ba31ff1a90da7efc4b6b33459f0d2f598b0 by Méven Car, on behalf of Alejandro Valdes.
Committed on 01/07/2019 at 17:40.
Pushed by meven into branch 'master'.

Added new Suspend then Hibernate option

Summary:
See [[ https://bugs.kde.org/show_bug.cgi?id=399727 | bug 399727 ]] for a good description of what this code is for.

The new ui will show a new option like the following image {F6349860}

Reviewers: broulik, ngraham, meven, davidedmundson, sitter

Reviewed By: ngraham, meven, davidedmundson, sitter

Subscribers: sitter, davidedmundson, ericadams, jobauer, reverendhomer, meven, soriano, abalaji, graesslin, ngraham, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D16425

M  +14   -9    daemon/actions/bundled/suspendsession.cpp
M  +1    -0    daemon/actions/bundled/suspendsession.h
M  +21   -3    daemon/actions/bundled/suspendsessionconfig.cpp
M  +2    -0    daemon/actions/bundled/suspendsessionconfig.h
M  +3    -0    daemon/backends/upower/login1suspendjob.cpp
M  +5    -0    daemon/backends/upower/powerdevilupowerbackend.cpp
M  +1    -1    daemon/backends/upower/upowersuspendjob.cpp
M  +6    -0    daemon/org.freedesktop.PowerManagement.xml
M  +2    -1    daemon/powerdevilbackendinterface.h
M  +5    -0    daemon/powerdevilfdoconnector.cpp
M  +3    -0    daemon/powerdevilfdoconnector.h
M  +34   -0    daemon/powerdevilpowermanagement.cpp
M  +4    -0    daemon/powerdevilpowermanagement.h

https://commits.kde.org/powerdevil/daa06ba31ff1a90da7efc4b6b33459f0d2f598b0

As someone who was looking for the suspend-then-sleep action in Plasma for quite some time, I was confused by the UI choice.

What I wanted to configure was suspend-then-sleep when closing the lid. I was looking for a respective option in the "Buttons event handling" section (which, btw, is also an odd name for lid-closing actions. I know it's correct from a technical point of view, but for non-technical users, it doesn't). I didn't see that I had to select "Suspend" there, and enable the "-then-hibernate" part in a different section that has nothing to do with lid closing (which is even above the "Buttons event handling" section).

FWIW, I liked the original suggestion with a separate "Sleep/Suspend, then hibernate" option much better, because it allowed for separate actions (with or without "-then-hibernate") for lid-closing, power button, and automatic timeout. This doesn't seem possible with the current UI.