Systemd supports four power-saving modes: suspend, hibernate, hybrid-sleep and suspend-then-hibernate. Very briefly each one behaves as follows:
- suspend: Save state to RAM, battery still drains at a slow rate, when drained completely you lose your data, fast sleep, fast resume
- hibernate: Save state to disk, battery does not drain (powered off), slow sleep, slow resume
- hybrid-sleep: Save state to RAM and disk, battery still drains at a slow rate, your data is safe if drained completely, slow sleep, fast resume (unless fully drained)
- suspend-then-hibernate: Save state to RAM, battery still drains at a slow rate. When the battery is low, it sends a signal that wakes the computer. Then it saves its state to disk and shuts off (hibernates). In this mode, sleep is fast and resume is fast unless the battery drains (slow resume). No data loss.
The above behavior applies to systemd 252, which was released 20 days ago. Manjaro still runs systemd 251, that behaves differently for the suspend-then-hibernate case:
suspend-then-hibernate
A low power state where the system is initially suspended (the state is stored in RAM).
If not interrupted within the delay specified by HibernateDelaySec=, the system will be
woken using an RTC alarm and hibernated (the state is then stored on disk).
In fact, this recent thread from the framework community warns of the change.
I do not use KDE so I cannot say what is happening in your system, but I assume checking the “While asleep, hibernate after a period of inactivity” box enables suspend-then-hibernate.
Since you are still running the old systemd, this explains why after you went into suspend-then-hibernate mode while your battery was low it drained completely: the expected behavior is to wake up after a certain time and then hibernate, but if the battery drains out before this can happen, then you lose your data.
This is actually the reason why the changes in systemd v252 were introduced (see the GitHub issue), to guarantee that the system goes into hibernation if the battery drains below a certain threshold in order to avoid data loss.
However, I believe this solution is still not ideal for framework laptop users, because of the still relatively high battery drain during suspend. With the old behavior, as long as you had sufficient power when closing the lid, you could open your laptop one week later and resume your work where you left it. With the new behavior, after a week you power on your laptop and then need to look for your charger in a rush because it is nearly drained.
The best solution in my opinion is a combination of both: after you close the lid, the computer can go into hibernation for two reasons; either sufficient time has passed, or battery is almost drained. This behavior avoids data loss while enabling both fast sleep, fast resume (at least for this “sufficient time”, after which resume is slow) and prevents excessive battery drain, so I think it is the best.
Fortunately, somebody already complained about the new behavior on the GitHub issue, and it seems systemd developers will change the behavior again to this last one I described for the next major release.
For the framework team: I believe it makes sense to make sure that the person you hired for Linux support has taken a look at the GitHub issue and even participates in the discussion/development if needed, since this is an important ux issue.