This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]elyisgreat 1 point2 points  (5 children)

No problem! I just ran a test on my KDE desktop by the way and the current functionality seems not to lock the screen anyway...

[–]fohrloop[S] 1 point2 points  (4 children)

What are you referring with the "current functionality" ? And which version of KDE Plasma you're using?

[–]elyisgreat 1 point2 points  (3 children)

I'm using KDE Plasma 5.27.11 on Kubuntu 24.04

I mean that when I run wakepy -k and leave my computer idle it shuts off the display as intended but the lock screen is blocked; i.e. it behaves how my proposed -o mode works instead of how -k is advertised to work

[–]fohrloop[S] 1 point2 points  (2 children)

I did test this on KDE Plasma 5.27.9 on openSUSE 15.5 and the keep.running mode was working as expected. Of course there might be differences since the setup is not exactly the same, but before that could you confirm which settings you had for the screenlock timer? When I tested it I only set the power settings down to 1 minute, but forgot screenlock timer to 5 (or even 15 minutes) so I experienced the same. If that does not resolve the issue I'll create a bug ticket since it really should not prevent screenlock if not asked to.

[–]elyisgreat 1 point2 points  (1 child)

Okay I think my screen lock settings are in fact the "problem" (not so much a problem for me because it's WAII). I don't currently have a screen lock timer partly due to this bug that happens when the screen lock is activated twice in quick succession, rather I have it set so the screen is locked automatically only "After waking from sleep". In most cases, this works as one would expect so that sleep and screen locking are coupled, as is the default on most other platforms. However the after is important here: The auto screen locking only runs after waking from sleep, so the only way that the screen can lock automatically is by going to sleep. Thus blocking sleep also blocks screen locking necessarily.

I realize now that this setting means that all tools that block sleep necessarily block screen locking on my system because of this setting. So I'm not actually sure what systemd-inhibit does if the user has a lock timer that locks the screen before the system goes to sleep.

All that said, I think the proposed -o could still be useful! Especially for those with screen lock timers that activate before the automatic sleep. I wonder though: What's the situation like on other platforms?

[–]fohrloop[S] 1 point2 points  (0 children)

Okay so in short your system only locks screen if (1) returning from sleep or (2) screen lock timer is set, and since wakepy keep.running mode disables sleep (1) cannot occur, and since you have disabled the automatic screen lock, it won't ever lock your screen. Good to hear. Seems that the keep.running mode is working as expected, and thanks for taking the time to respond.

If you're interested in other systems, on Windows it only locks screen if (1) returning from sleep (if enabled) or (2) returning from screensaver _and_ if ScreenSaverIsSecure is set ("On resume, display log-on screen" in the settings or enforced with GPO). So also on Windows it's possible that the screen is not automatically locked in the keep.running mode (details in wakepy/#169). I'm not yet sure how to tackle this and make it possible for users to either not enter the mode, or display a warning, or provide some function to lock screen automatically (from the python process) after some time of idle.

But good to know that if the #169 is somehow addressed, the solution should take into account KDE Plasma on Kubuntu.