Open pizdjuk opened 3 years ago
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
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.
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.
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.
This solution sounds pretty good and consistent!
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