SUMMARY There seems to be an issue where power management turns off the screen despite being suppressed, and the lock screen correctly does not trigger. I'm marking this as critical because it has resulted in me leaking my password several times, under the assumption that if my screen is off I need to enter my password (because if my screen is off, based on the timers, the lock screen should've triggered). This is a workflow that's been fine for years, and I'm sure others have picked it up. STEPS TO REPRODUCE 1. Set screen locker to auto lock after 1 minute, and power management to shut the screen off after 2 minutes 2. Play music with elisa 3. Wait OBSERVED RESULT The screen shuts off without locking. EXPECTED RESULT The screen does not shut off and does not lock. SOFTWARE/OS VERSIONS Kernel: 5.10.16-200.fc33.x86_64 KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.78.0 Qt Version: 5.15.2
It may be the case that this should actually be filed against the screen locker. I'm unsure if there is a specific kind of power suppression that should suppress sleep but not screen off -- if so, this is definitely an issue there instead.
Also worth noting this is not specific to Elisa's power management suppression implementation. This is a general problem that affects other music players doing power management suppression (also reproducible with Rhythmbox). Additionally, it may not be immediately obvious why this is such a severe problem -- as some screens turn on very quickly. However, monitors like the ones I'm using take several seconds to turn on, which is more than enough time for a fast typer to enter their passsword, and hit enter. Additionally monitors like these increase the likelihood of picking up this habit as wiggling the mouse before entering your password results in a fair bit longer waiting period.
Why should the screen not turn off when playing *music*? The bug I see here is that the screen does not lock even though the screen turns off.
(In reply to Kai Uwe Broulik from comment #3) > Why should the screen not turn off when playing *music*? The bug I see here > is that the screen does not lock even though the screen turns off. See my second comment :) > It may be the case that this should actually be filed against the screen locker. > I'm unsure if there is a specific kind of power suppression that should suppress > sleep but not screen off -- if so, this is definitely an issue there instead. Testing quickly with a video in Firefox, the screen does not turn off. So I'm guessing it is the case that there is some way of differentiating? In which case this should probably be moved?
Oh, I think I know what's going on: KScreenLocker asks PowerDevil for inhibitions and PowerDevil just sends them all out, no matter if they are screen or suspend. I guess that needs to be split. I've wanted to do that for a while so Battery Monitor can also show that in more detail.
Going to add to this, Elisa can actually suppress the lock screen from appearing without power management reporting anything in the Battery & Brightness portion of the system tray. i.e. there seems to be a related issue where apps aren't even visibly reported as triggering power suppression.
(In reply to Wyatt Childers from comment #6) > Going to add to this, Elisa can actually suppress the lock screen from > appearing without power management reporting anything in the Battery & > Brightness portion of the system tray. > > i.e. there seems to be a related issue where apps aren't even visibly > reported as triggering power suppression. Additional bug filed for this in: https://bugs.kde.org/show_bug.cgi?id=433627
Ok perhaps i just need to try with Elisa then :)
Thank you for the bug report. It's been a while since this was last updated. Did you file the issue with the Elisa project? Has the issue been fixed or is there still a problem?
(In reply to TraceyC from comment #9) > Thank you for the bug report. It's been a while since this was last updated. > Did you file the issue with the Elisa project? Has the issue been fixed or > is there still a problem? Yes, on an almost daily basis.
Too add extra context, I see this with firefox and moonlight. Maybe it's just anything coming from a flatpak is reported in the UI but doesn't actually affect anything.
Yes, that's exactly it. This is caused by packaging bugs for those Flatpaked apps; see Bug 485376. *** This bug has been marked as a duplicate of bug 485376 ***
*** This bug has been marked as a duplicate of bug 486506 ***