Even though my laptop supports hybrid-suspend very well, KDE doesn't seem to want to use it, and there doesn't seem to be a way to configure this. I'm quite sure hybrid suspend works as expected: "systemctl hybrid-sleep" works as expected, and after adding "HandleLidSwitch=hybrid-sleep" to /etc/systemd/logind.conf, the laptop automatically hybrid-sleeps when the lid is closed. Unless KDE is running, that is.... Note that KDE seems aware that my system supports hybrid sleep: > bas@miranda]~> qdbus org.freedesktop.PowerManagement /org/freedesktop/PowerManagement org.freedesktop.PowerManagement.CanHybridSuspend > true However, there is no way to explicitly specify hybrid-sleep in the config panel (just sleep and hibernate). A number of other bug reports seem to indicate that KDE should automatically shoudl hybrid-sleep instead of sleep, if it is available, but it is inclear if that was ever implemented. It doesn't work here, at least: I've added a script "echo "$(date) $0 $1 $2 >> /tmp/pmlog" to /lib/systemd/system/sleep/, which clearly shows that systemd is running "suspend" instead of "hybrid-sleep". Reproducible: Always Steps to Reproduce: 1. close laptop lid 2. 3. Actual Results: system suspends Expected Results: system should have hybrid-suspended.
I think it's just that we don't have an entry for that in Kickoff and the like. Probably needs to be added in various places.
(In reply to Kai Uwe Broulik from comment #1) > I think it's just that we don't have an entry for that in Kickoff and the > like. Probably needs to be added in various places. or maybe use HybridSuspend instead of Suspend if available. I am not sure whether it makes sense to expose such a fine grained difference to the user.
Either solution would be fine with me. If you could point me to the component in which suspend/hibernate is handled, I could probably come up with a patch.
(In reply to Martin Gräßlin from comment #2) > or maybe use HybridSuspend instead of Suspend if available. I am not sure > whether it makes sense to expose such a fine grained difference to the user. A "Use Hybrid-Suspend if available" checkbox in PowerDevil settings would be a nice and simple way how to expose this feature.
An ugly workaround: 1. In PowerDevil settings, set lid close action to "Do nothing" in all profiles 2. Add this to /etc/systemd/logind.conf : HandleLidSwitch=hybrid-sleep 3. Restart logind: systemctl restart systemd-logind 4. Download fdmanage.py, make it executable and put in your PATH: https://raw.githubusercontent.com/ticpu/tools/master/fdmanage.py 5. Add this to session autostart (edit /etc/sudoers to enable running as root without password): sudo fdmanage.py $(lsof -c kded5 2>/dev/null | grep /run/systemd/inhibit/ | awk '{gsub("w",""); print $2 " " $4; exit}') This will release PowerDevil's inhibit lock and will let logind to manage the lid-close action instead.
Usability: What do you think? Should we make "Hybrid Suspend" another option in addition to Suspend to RAM and Suspend to Disk, ie. expose that in PowerDevil settings, Kickoff, and what not. Or should we add a "[X] Use hybrid suspend" (with a whats this text, I'm open for better wording) checkbox which makes "suspend to ram" just hybrid suspend and done? That checkbox should only appear if the system is confgiured for hybrid suspend I guess. Also, I'm not sure whether to place it on the "advanced" tab of PowerDevil since it affects multiple actions or next to the "when power button is pressed" or elsewhere? Other suggestions? Also, I'm not sure how well we support that right now, I haven't managed to set it up on my machine so far :) I heard some people say that while it's suspending you just get a black screen forever? Or is this the Distro's job to show a Plymouth screen for that? Or do we need to show a spinny thing? Dunno ...
My first thought was to agree with the checkbox. But actually it's an intermediate method suspending to both RAM and disk. If you could place the checkbox at either hibernate or suspend it makes no sense. By the way: I like the description in the Arch wiki with "Suspend to RAM/disk/both". From the usability POV even a third option (aka radio button) is not a good solution. Strictly speaking it's not an exclusive setting. "Both" implies rather to have checkboxes for RAM (or hibernate) and disk (aka suspend, I may have mixed the terms), and checking both means hybrid-suspense. If I understand the underlying functionality right it works exactly in this way: you have the current state in both RAM and on disk allowing to wake-up quickly from RAM with the safety of a backup on disk when you run of of battery.
I like the idea of using "suspend to disk/mem/both", although I'm not sure what the best UI is to express this choice (using a dropdown with the three options, or using two checkboxes). In any case, I would prefer exposing the three methods on equal footing in the "Power Management" module of the system settings, rather than hiding the "use hybrid suspend" option somewhere in an advances settings screen.
I would vote for adding "both" to the dropdown selections rather than just a checkbox -- users might want to choose hybrid suspend when suspending on a critical battery, but just regular suspend when suspending on a lid close, for example.
IMHO the problem starts with Powerdevil _unconditionally_ inhibiting Systemd.Logind actions, even though it might have been set to "No Action". See: PolicyAgent::setupSystemdInhibition() - no check about responsibility of Powerdevil for the required action - just dumb "block" of all available events Why doesnt Powerdevil take its own configuration into account? This is very aggressive and annoying, and leads to ugly workarounds like above. Test: disable handling of Button events - inhibitions are not removed!
If you set button handling to *no action* this doesn't mean some other service should randomly do stuff instead...
(In reply to Kai Uwe Broulik from comment #11) > If you set button handling to *no action* this doesn't mean some other > service should randomly do stuff instead... After having thought heavily about your statement I come to the conclusion: - you read *no action* as: no action by anything in this system - I read *no action* as: no action by Powerdevil It boils down to the question "who rules" - take it or leave it. As the workarounds like above show, I am not the only one irritated by Powerdevils policy.
If the average user configures it for "no action" this means no action whatsoever. A user should not need to know there's a ton of different services who all mess with his or her session in different ways.
systemctl has actions sleep, hybrid-sleep, hibernate, poweroff. I think making menu for lid actions match this would keep both the code and UI simpler than the checkbox option. But any form of hybrid-sleep support would be preferred.
The lack of hybrid suspend support in KDE/Plasma has been discussed for several years now. Instead of getting bogged down in implementation details, just add the option in any form, it can always be improved later. Laptop users need the option now, not in another 5 years when someone finally makes an executive decision. If no-one currently active on the project is able (too busy) or interested in implementing this, then please tell us now so that one of us from the community can step up and do it instead.
> If no-one currently active on the project is able (too busy) or > interested in > implementing this, then please tell us now so that one of us from the > community > can step up and do it instead. we are a community of mostly volunteers. One of the base principals is scratch your own itch. If you want to have this feature: work on it. Don't wait for anyone telling you, that you should work on it. Just do.
I completely understand the volunteer nature of the project, I've been an open source contributor for well over 10 years now. However no-one wants to waste their time working on a solution when there is one already in progress by someone in the core team. I'm going to take it from your response that it isn't currently the case, so yes, time permitting (and it generally doesn't these days), I will work on it myself.
What is the status of this support? Is it still only discussed/tracked here? If the feature is not difficult to add/contribute, can an experienced dev familiar with the codebase point out what needs to be done where?(files to change, UI adjustments, etc) From what I gather reading this, adding the basic functionality to the launcher leave options is trivial?(if so what files/lines? for launcher support) Followed by some UI settings modification(System Settings -> Power Management -> Advanced Settings?) and extra changes elsewhere to support laptop lid behaviour? --- I'm in agreement with getting this 5 year old request(https://bugs.kde.org/show_bug.cgi?id=302968) functional and available, tweak the UI later if there is a need. Even just having it as a launcher option would be nice(I noticed Power Management -> Energy Saving has a dropdown for the power button action supporting hybrid-sleep). While benefits are obvious for laptop users, it's also useful as a desktop user, I would prefer it.
Wow, this bug exists since 2012! When KDE 4 was still normal. More than 5½ years now. https://bugs.kde.org/show_bug.cgi?id=302968#c0 An example of where the “nobody’s responsibility” culture of most open source projects fails. And the most-discussed thing in those years, was whether the user should be treated like a moron. (Which usually follows the great motto of coprorations: “Treat the user like a moron *until he is*.” Shifting the bell cure of stupidity downwards, resulting in even dumber users and hence even lower expectations, in a vicious cycle that ends up with nightmares like iOS or Windows 8 or Ubuntu Unity or MS Bob and Clippy.) … I tried to add this functionality myself. But the KDE code is a combination of such horribly bad and outdated languages and massive gigantic heaps of boilerplate and bloat, together with a lack of actual documentation, that it hurts too much to even try to understand it. So I understand well, why things like this aren’t just fixed by a volunteer (or even regular). When you discover you’re riding a dead horse, … dismount. *dismounts*
This bug is actually fixed for almost an year. The commit that fixed it was made in March last year https://cgit.kde.org/powerdevil.git/commit/?id=c6b76da7a67977deacadb65e6e9d1713e8b3f7b6 that added hybid-suspend as an option to the lid-close and power-button actions. But while the bug itself is closed, hybrid suspend is still not a first class citizen in plasma, I suppose this is why the bug remained open. There is still no way to trigger hybrid-suspend on demand (from the start menu or from the logout applet). BTW, I'm not a KDE developer and had nothing to do with the actual fix.
Thanks for confirming! If we need another bug to track additional work, we should do that.