Configurable suspend in place of hybrid-sleep

[pizdjuk]

It would be perfect if it were an option to select true suspend, and no hybrid sleep.

At now "suspend" in mate-power-manager means actually hybrid-sleep.
This is confusing. Because I prefer to use suspend over hybrid-sleep to not use my SSD without a need. And it takes fewer time to go to suspend then to hybrid sleep.

I'm using MATE 1.24.0

Workaround: disable hybrid-speed at system-level adding the line

AllowHybridSleep=no

to /etc/systemd/sleep.conf

[lukefromdc]

This sort of thing is one more reason why encrypted computers must never have unencrypted swap space. With swap space encrypted with random numbers this could lead to data loss (not as bad as data capture by an enemy) unless something is disabling hybrid sleep when any LUKS keys are present. This is actually the first I've heard of hybrid sleep, and it makes me damned glad I normally configure encrypted machines with plenty of RAM and zero swap space. I will take an out of memory crash over a data leak after a hardware theft anytime

[thomas-t-w]

I think this is a more complicated issue. I actually think that the critical preference on battery needs to be completely removed from Mate. It used to be that the power manager read the status from upower and performed actions based on what it read. Now upower actually performs the actions via logind itself, see /etc/Upower/Upower.conf where a critical battery action is defined. The ability to set the critical battery action was removed from gnome for this reason. From looking at Upower related things, this change was made so that even if a desktop session was not running, the critical action could be performed. I think that if a suspend option is desired, this needs to be discussed with Upower upstream. The critical action should probably be removed from mate preferences with a note stating that users must configure the critical action via Upower.conf. I couldn't find any ways to modify what Upowe does via dbus. I'm still investigating this, but I started because I noticed that after my laptop went to sleep due to low battery, when I would wake it up, it would hibernate again. This may indicate that both Upower and Mate are trying to perform an action on critical battery. The only way I could see retaining the critical action selection in Mate would be to fork Upower, which seems highly undesirable to me.

[thomas-t-w]

I can almost certainly confirm the double action. When I set Mate preferences to do nothing, laptop enters hybrid sleep and wakes as expected, however, when Mate Preferences are set to hibernate, laptop immediately wakes and enters hibernate again. Mate screensaver does not lock when Upower puts the machine to sleep with the mate action set to do nothing, so I think it needs to listen for some signal. @pizdjuk, I think you should open the request for a suspend option with upstream Upower if you still desire this. I will try to work on removing the critical action from Mate, however , I would appreciate help as my c skills are not very good and I am more familiar with Python. The things I see needed are:
1: remove preference from mate and add note on how the preference can be configured in upower.conf.
2: Figure out what signal Mate Screensaver needs to listen for. Upower must emit a dbus signal before it performs its action, for the benefit of screen lockers (Gnome must lock itself somehow.

[thomas-t-w]

I have been thinking about this for the past few days. I think there is a better way than what I suggested above. I would like feedback before I begin the work.

1. Leave the critical battery options in mate. A suspend action and hybrid sleep could be added as options.
2. Rename "do nothing" in the critical battery action to "do nothing (control by upower)." and set this as the default in upstream mate.
3. If the user tried to change the critical battery setting in mate, let them know that they need to disable the hybrid-sleep in Upower.conf to avoid a conflict.
   The cases above solve two problems:
   For one common use case, it provides a sane configuration for users who install distros like Arch that ship upstream packages without modifications (upower performing hybrid sleep on criical battery). In this case, upower would perform its criical battery action and Mate would not.
   The other common use case I see is distros that ship an out of the box Mate experience. As part of preparing their distro, the maintainer could disable the upower critical battery action in Upower.conf and then turn on a critical battery action for their users in mate. by default This would let users have control of the battery action in the gui.

[pizdjuk]

This solution sounds pretty good and consistent!