SUMMARY Power management suppression can't be ignored for nasty applications that don't really need to suppress power management. STEPS TO REPRODUCE 1. Install Steam, or have some ad play silently in some tab in Chrome or Chromium 2. See how power management is suppressed. Reason being inane "My SDL application" is "Playing a game" which is actually Steam, not actually running any games. 3. Watch your computer corrupt data because it isn't shut down properly on low battery. Watch your computer never lock your screen (**security issue!**) and/or cause screen burn-in. It's actually really-really horrible. OBSERVED RESULT Data corruption due to power management being suppressed incorrectly EXPECTED RESULT That it's possible to ignore power management suppression by nasty applications that won't ever be fixed. Applications like Steam are notorious for not playing nicely with DEs. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 20.04 KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8
Hmm i thought it would still suspend on critical battery regardless: https://invent.kde.org/plasma/powerdevil/-/blob/master/daemon/powerdevilcore.cpp#L755 Being able to override inhibitions has been my idea forever but haven't come to implementing that yet.
I hoped so as well, but I found my laptop with a flat battery and an unclean shutdown. Next boot I noticed Steam's tendency to incorrectly suppress power management.
So you want power management suppression suppression? lol A quick search didn't show an open bug for this at https://github.com/ValveSoftware/steam-for-linux/issues. Can you please file one and then mention the UL for it here?
Valve is rather unresponsive to issues on their bug tracker. I can't hope it will be fixed, remains fixed. Plus this issue is not really Steam specific, Steam is just a very good example of a misbehaving application. > A quick search didn't show an open bug for this at There's a few but it's irrelevant really. https://github.com/ValveSoftware/steam-for-linux/issues/5532
Just noticed that this is marked as wishlist, I don't see how it really is wishlist if it is an actual issue with certain software. Please at least move set it to minor.
Don't worry, "wishlist" doesn't mean it's less important than "minor."
That doesn't really comfort me because I did have my laptop run out of battery, failing next boot (needed fsck). I would hate if something similar happened and my VM or something got corrupted.
Fair point.
I've just came here searching for resolution of my problem - it's not as severe as system corruption but it's really annoying,,, I was trying to set-up automatic screen locking in KDE - it wasn't locking properly after the timeout. After some search I found the reason - it's Chrome inhibiting power management with "WebRTC has active PeerConnections". Yes - I have an app active that uses WebRTC, but locking the screen manually doesn't harm the app - after unlock connection is still intact and everything works fine. So it would be great if the suppression from being possible at all had some grading for it - like "suppress inhibition for screen lock", "suppress inhibition for all cases" etc. But I'll take even simple "suppress inhibition from this one app" :)
We have a command-line utility that can do this now. The more I think about it, the more I think you may have a point. It doesn't seem unreasonable to add a tiny tiny UI to the applet that lets you delete inhibitions. Like maybe a trash button can appear on hover, we do in many other places.
> We have a command-line utility that can do this now. Which?
Maybe I was on crack that day; now I can't remember what I was thinking about when I said we have a tool to do this.
Maybe you were thinking of kde-inhibit? It doesn't delete inhibitions though, it just *adds* an inhibition while a specified command runs.
*** Bug 464659 has been marked as a duplicate of this bug. ***
Not certain if this would be relevant or not, but Steam also hijacks the shutdown process as well, not letting the system shut down until it has gracefully exited which can often times lead to waiting for 10, 20 or 30 seconds extra just to have the computer turn off. (depending on how leisurely steam is feeling that day) Having some sort of power management override to stop certain applications from blocking screen lock, blocking sleep, blocking shut down, etc. would definitely be a massive QoL improvement. In hindsight, I think I've actually personally lost data before for this exact reason since I had a few times where my laptop didn't sleep when it should have and died on me, didn't realise steam was blocking this at the time.
This sounds like it's actually trying to address 2 separate issues: - Certain actions like a power management action taken on low battery status likely shouldn't be possible to inhibit. I wouldn't leave this matter up to what would be essentially a power management inhibition blacklist, but some events should just ignore inhibitions. For example going sleep when idle makes sense to be possible to inhibit as idle doesn't necessarily mean no user activity, but taking action on low battery or lid closing really shouldn't have anything in the way. - Would be great to be able to ignore inhibitions of misbehaving programs. Likely Bug 460125 is relevant to this, but then there's also the problem that quite a few programs encapsulate others which would make the usefulness of such feature limited in some cases. For example if we ever get audio-specific power management inhibition, then the not so rare silly problem of malicious websites doing audio fingerprinting and keeping something audio output related around would be one annoyance this couldn't handle as this could only block the browser completely.
My biggest concern is about screen lock. Having a machine that does not lock while the user expects it to do so and maybe walks away is a big security concern. I agree that it is nice to have your machine not going into screen lock when you are watching a movie, but IMHO the default should be to lock and apps should be enabled to get permission to inhibit lock as an opt-in and on a per app basis. Incidentally note that a user may somehow expect a machine not to lock when playing a video, but he would most definitely expect it to lock while playing audio. However there are apps that while playing audio only still inhibit screen lock.
(In reply to Nate Graham from comment #3) > So you want power management suppression suppression? lol Not as "lol" as it may at first sound. There are always apps which abuse the inhibition. Here is a fresh example from the [Gnome code monkes](https://idiod.video/11d2fd.png): It doesn't allow to turn off screen, coz it's downloading something in background. So they srsly expect monitor not going to sleep for many hours of download. So the ability to easily reset all the inhibition tokens from the UI would be really awesome and not that hard to do. P.S. in that particular case even killing the boxes app doesn't help, since it's a flatpak one, and i assume flatpak somehow proxies (an hence keeps alive) the DBUS connection for it. So the monitor never sleeps anymore.
(In reply to Nate Graham from comment #12) > Maybe I was on crack that day; now I can't remember what I was thinking > about when I said we have a tool to do this. systemctl --user restart plasma-powerdevil.service does it for me on ubuntu. But this might be distro specific.
Occasionally, my notebook did not sleep after closing the lid and packing it into my bag. It overheats and drains all the battery. After digging I found out, that Threema ist using WebRTC, that prevents sleep from happening. A little UI would be very helpful. But until then, is there a workaround on how to prevent an app from letting the PC sleep? I'm worried about my computer :) An even bolder idea: it took me quite some time to figure out where I find the app that is preventing sleep. How about: - if the lid gets closed - sleep on lid closed is activated - app is preventing sleep - show a notification (permanent) what is preventing sleep This combination might seem a bit random, but it's the default that most users have and expect. It's always something that I admire about MacOS. It sleeps when it has to
Forget about my comment, I missunderstood the behavior of "prevent sleep". If lid action is set to sleep, it will sleep anyway. I had a special setting that only turns off the screen on lid close and then sleeps after 3 minutes. And in that case, the computer won't sleep anymore if an app prevents it. So the average user won't be affected by it. And it's my workaround, I'm happy :)
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4263
(In reply to Bug Janitor Service from comment #22) > A possibly relevant merge request was started @ > https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4263 cool. will this button block an app permanently? until prohibit entry disapears? until kwin session stopped?
(In reply to Marco Schmidlin from comment #23) > (In reply to Bug Janitor Service from comment #22) > > A possibly relevant merge request was started @ > > https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4263 > > cool. will this button block an app permanently? until prohibit entry > disapears? until kwin session stopped? Until it posts another inhibition. I imagine blocking apps permanently would have use cases too but this would become more complicated as we'd need a UI to undo block-blocks which the applet is perhaps not well suited for.
(In reply to Marco Schmidlin from comment #23) > (In reply to Bug Janitor Service from comment #22) > > A possibly relevant merge request was started @ > > https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4263 > > cool. will this button block an app permanently? until prohibit entry > disapears? until kwin session stopped? Hm, assuming that permanently block-blocking an app/reason combination would be the more common use case, I suppose we could turn it into a "Permanently unblock" function, then show a informational message a la "x has been prevented from blocking sleep" alongside an "Allow again" button. But this would mean completely scraping doing over this MR, so I'd like to vollrct more feedback on the current version first.