Bug 512607

Summary: Standby, then hibernate: behaviour differs if manually initiated via launcher vs. automatically initiated via lid closure / timeout
Product: [Applications] systemsettings Reporter: Paul Leiber <paul.leiber>
Component: kcm_powerdevilAssignee: Plasma Bugs List <plasma-bugs-null>
Status: RESOLVED DUPLICATE    
Severity: normal CC: kde, natalie_clarius, private_lock
Priority: NOR    
Version First Reported In: git-stable-Plasma/6.3   
Target Milestone: ---   
Platform: Debian stable   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Paul Leiber 2025-11-25 20:31:30 UTC 
SUMMARY

While testing "standby, then hibernate" from KDE settings, it was observed that hibernate after standby is entered if standby has been induced via laptop lid closure or via inactivity timeout. If standby is induced via menu launcher -> Standby, it stays in standby and doesn't enter hibernation. This behaviour is inconsistent from the user's perspective.

STEPS TO REPRODUCE
1. Set "Standby, then hibernate" in KDE settings.
2. Initiate standby manually.
3. Wait for hibernation, which isn't entered.
4. Start system
5. Wait for standby due to inactivity timer or close lid of laptop
6. Wait for hibernation, which is entered after the value set in HibernateDelaySec 

OBSERVED RESULT
Inconsistent behaviour: Hibernation after standby is entered in one way, but not the other.

EXPECTED RESULT
Consistent behaviour: Hibernation after standby should always be entered, independent from the way standby is initiated.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma:  6.3.6
KDE Plasma Version: 6.3.6
KDE Frameworks Version: 6.13.0
Qt Version: 6.8.2

ADDITIONAL INFORMATION
During testing, I initially thought that "Standby, then hibernate" doesn't work at all, because I always initiated standby manually via the launcher menu. Only after closing the laptop lid, I observed the desired behaviour. See comment bug report https://bugs.kde.org/show_bug.cgi?id=462617
Comment 1 Holger 2025-12-21 20:48:49 UTC 

*** This bug has been marked as a duplicate of bug 509591 ***