----- Original Message ----- > Hello, > > a few days back I noticed that my F29 laptop is hibernated every morning even > though I suspended it the previous evening. After some digging, it seems > that there's a new "systemctl suspend-then-hibernate" command that does > exactly this (with a 3 hour delay) and gnome seems to execute it > automatically instead of the classic "systemctl suspend". > > On one hand, this is absolutely awesome, and I've been wanting this for ages. > Windows can do it, general users are used to this, and are usually very > surprised when they have a Fedora laptop that drains their battery to 0% > during a few days long suspend (that's the case for my wife and my parents). > > On the other hand, I'm a bit concerned that the default behavior changed > unannounced and doesn't even seem configurable. In gnome-control-center, my > power button action is configured to "suspend", yet it clearly performs > "suspend-then-hibernate". There seems to be no way to opt out of this and > use just a classic suspend. Another question is what happens if > hibernation/resuming is not configured properly (swap partition missing, > resume= argument missing, etc). Have those edge cases been covered? > > So, my questions are - has this been a deliberate change or is it just some > happy coincidence of some systemd+gnome interactions? Will there be some > release notes for the users announcing the change? Do plan to make it > configurable (allowing users to select between suspend and > suspend-then-hibernate)? Should we focus on testing the corner cases? > > Thanks. https://gitlab.gnome.org/GNOME/gnome-settings-daemon/commit/a6e3ee40d90294c603e1108e19ef8fe8e6af61eb _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@xxxxxxxxxxxxxxxxxxxxxxx