SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** After recent plasma's screensaver behavior changes, plasma now doesn't take into account screensaver inhibitors that come from non focused apps. This is a correct behavior, however, while screen dimming works in that case, automatic screen locking doesn't work. Some apps do dim screen inhibiting randomly (for example, steam) and this can lead to unexpected results, as the user may think that if the screen turns off and nothing interferes with it, then the system should be locked as specified in the settings, but because it doesn't trigger screen locking, unwanted persons can access the OS. STEPS TO REPRODUCE 1. Set both screen dimming and auto locking timeout to 1 minute 2. Open some video in a chromium (so it will inhibit screen dimming) 3. Minimize this window OBSERVED RESULT Screensaver works but after 1 minute OS is still unlocked EXPECTED RESULT Both screensaver and automatic screen locking works SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Arch Linux (available in About System) KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.4 ADDITIONAL INFORMATION Wayland/Xorg
Open the Battery & Brightness applet in your System Tray; what does it say about Chromium?
(In reply to Nate Graham from comment #1) > Open the Battery & Brightness applet in your System Tray; what does it say > about Chromium? "Chromium is currently blocking sleep and screen locking (playing audio)" (when minimized) This bug also occurs when lutris blocks sleep with "running game" message. Also, maybe it's little off topic, but in xorg firefox after minimizing removes it's inhibitor, but for wayland it doesn't. That's weird because wayland also sends minimize event? So it's probably either firefox wayland implementation bug or xwayland bug?
So yeah, it's doing what it says: blocking sleep and screen locking. Are you saying that something different happened in the past? If so, specifically what? What changed, and when?
(In reply to Nate Graham from comment #3) > So yeah, it's doing what it says: blocking sleep and screen locking. > > Are you saying that something different happened in the past? If so, > specifically what? What changed, and when? So it blocks sleep (system sleep or "suspend") and screen locking but not display sleeping? In the past (before plasma 5.24, it seems) I think it wouldn't trigger monitor sleep at all when there's any inhibitor that blocks somethings even with minimized window or locked screen.
I can't remember if inhibitions are universal, or an app gets to choose what to inhibit. Hopefully the Powerdevil developers can help some more.
(In reply to Nate Graham from comment #5) > I can't remember if inhibitions are universal, or an app gets to choose what > to inhibit. Hopefully the Powerdevil developers can help some more. Looks like I didn't understand the problem correctly. Lutris (which has the problem I described) uses Gtk.Application.inhibit with GTK_APPLICATION_INHIBIT_SUSPEND and GTK_APPLICATION_INHIBIT_IDLE flags. GTK_APPLICATION_INHIBIT_IDLE flag should inhibit both dim screen and lock screen (if I understood correctly from https://docs.gtk.org/gtk3/flags.ApplicationInhibitFlags.html) but powerdevil(?) interprets it as "disable lock screen but not dim screen" so it's probably powerdevil's regression. But it only work not intended when an app is not in focus. It's a bug anyway because it either should ignore inhibitors for minimized apps or respect them fully anywhere except lock screen. Blocking auto locking and not screen dimming is confusing.
(In reply to Artur Rudenko from comment #6) > (In reply to Nate Graham from comment #5) > > I can't remember if inhibitions are universal, or an app gets to choose what > > to inhibit. Hopefully the Powerdevil developers can help some more. > > Looks like I didn't understand the problem correctly. Lutris (which has the > problem I described) uses Gtk.Application.inhibit with > GTK_APPLICATION_INHIBIT_SUSPEND and GTK_APPLICATION_INHIBIT_IDLE flags. > GTK_APPLICATION_INHIBIT_IDLE flag should inhibit both dim screen and lock > screen (if I understood correctly from > https://docs.gtk.org/gtk3/flags.ApplicationInhibitFlags.html) but > powerdevil(?) interprets it as "disable lock screen but not dim screen" so > it's probably powerdevil's regression. But it only work not intended when an > app is not in focus. > > It's a bug anyway because it either should ignore inhibitors for minimized > apps or respect them fully anywhere except lock screen. Blocking auto > locking and not screen dimming is confusing. In addition, because of this bug, lutris now can't block screen dimming for games anymore.
Could you please post the output of qdbus --literal org.kde.Solid.PowerManagement.PolicyAgent /org/kde/Solid/PowerManagement/PolicyAgent org.kde.Solid.PowerManagement.PolicyAgent.ListInhibitions while a video is running?
(In reply to Natalie Clarius from comment #8) > Could you please post the output of > > qdbus --literal org.kde.Solid.PowerManagement.PolicyAgent > /org/kde/Solid/PowerManagement/PolicyAgent > org.kde.Solid.PowerManagement.PolicyAgent.ListInhibitions > > while a video is running? Nevermind, that info is already covered by what you gave above.
Also, please check again in Plasma 6.1, as a lot has changed with respect to power management since 5.24.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.