SUMMARY By default, when an application inhibits suspend (which a lot of applications do falsely, e.g. by having a paused video block suspend even though no playback is occurring) KDE will no longer allow suspend on the lock screen at all and no longer allow it with unlocked session either without entering the admin password. There also doesn't seem to be a setting in "Security & Privacy" in the KDE System Settings to change this. This seems questionable behavior to me on a device the user physically has in front of them, outside of rare kiosk setups, since the user can typically just unplug or force shutdown the device in some way. On portable devices like laptop especially it can at the same time be highly disruptive, e.g. I want to leave the house and take the device with me and need to suspend it for that purpose before putting it in my backpack. But now with a screen lock engaged this process becomes very cumbersome, requiring two password prompts, rather than just one button press. My apologies if I'm missing something that actually makes this important or more reasonable than I thought! I just couldn't think of what that could be at the time of filing. STEPS TO REPRODUCE 1. Have any app inhibit suspend 2. Use Super+L to lock screen 3. Press "Sleep" button on lock screen OBSERVED RESULT Nothing happens. If you unlock the session again which is somewhat elaborate to do, there will be an admin password prompt. Without also entering that admin pw prompt, there's no apparent way to suspend. There is no "Security & Privacy" setting that I can find that allows changing this behavior that is probably a mismatch for many users' use cases. EXPECTED RESULT There is a setting to achieve the following behavior: suspend always works with no admin pw prompt, especially also keeps working from the lock screen without unlocking. Maybe this behavior should also be the default value of the setting. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: postmarketOS Edge (available in About System) KDE Plasma Version: 6.1.2 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 ADDITIONAL INFORMATION
This is not the case by default: Can you run: qdbus --system org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.CanSuspend
Oops I'm sorry, it seems like you are correct: I noticed this happens with a different desktop environment on this distribution as well, and it seems to be related to that Linux distribution. I reiled the bug with them, hoping to get this looked into.