Summary: | Power management ignores sleep and screen locking suppression | ||
---|---|---|---|
Product: | [Unmaintained] Powerdevil | Reporter: | Wyatt Childers <kdebugs.81do7> |
Component: | general | Assignee: | Plasma Bugs List <plasma-bugs-null> |
Status: | RESOLVED DUPLICATE | ||
Severity: | critical | CC: | kde, kdedev, nate |
Priority: | NOR | ||
Version First Reported In: | 5.20.5 | ||
Target Milestone: | --- | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
See Also: | https://bugs.kde.org/show_bug.cgi?id=432792 | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Wyatt Childers
2021-02-22 22:46:47 UTC
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 *** |