Bug 423745

Summary: Add the ability to override apps that are inhibiting power management
Product: [Plasma] plasmashell Reporter: Avamander <Avamander>
Component: Battery MonitorAssignee: Natalie Clarius <natalie_clarius>
Status: ASSIGNED ---    
Severity: wishlist CC: Avamander, bharadwaj.raju777, jacob, je2, jpetso, kde, kde, matamba10, matofesi, natalie_clarius, nate, nerumo, plasma-bugs, sergio.callegari, severin.hamader, spamless.9v5xj, tani.giovonni, voidpointertonull+bugskdeorg
Priority: NOR    
Version: master   
Target Milestone: 1.0   
Platform: Kubuntu   
OS: Linux   
See Also: https://bugs.kde.org/show_bug.cgi?id=455134
Latest Commit: Version Fixed In:

Description Avamander 2020-07-01 14:07:17 UTC
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
Comment 1 Kai Uwe Broulik 2020-07-01 14:29:48 UTC
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.
Comment 2 Avamander 2020-07-01 14:39:54 UTC
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.
Comment 3 Nate Graham 2020-07-02 01:20:51 UTC
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?
Comment 4 Avamander 2020-07-02 01:24:00 UTC
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
Comment 5 Avamander 2020-07-02 18:46:01 UTC
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.
Comment 6 Nate Graham 2020-07-07 18:18:59 UTC
Don't worry, "wishlist" doesn't mean it's less important than "minor."
Comment 7 Avamander 2020-07-16 14:21:19 UTC
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.
Comment 8 Nate Graham 2020-07-16 19:02:04 UTC
Fair point.
Comment 9 Maciej J . Woloszyk 2020-10-02 14:00:44 UTC
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" :)
Comment 10 Nate Graham 2020-10-02 16:43:57 UTC
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.
Comment 11 Bharadwaj Raju 2022-09-30 09:38:04 UTC
> We have a command-line utility that can do this now.

Which?
Comment 12 Nate Graham 2022-10-09 19:08:00 UTC
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.
Comment 13 Bharadwaj Raju 2022-10-09 20:15:30 UTC
Maybe you were thinking of kde-inhibit? It doesn't delete inhibitions though, it just *adds* an inhibition while a specified command runs.
Comment 14 Nate Graham 2023-01-24 18:10:39 UTC
*** Bug 464659 has been marked as a duplicate of this bug. ***
Comment 15 tani.giovonni 2023-08-09 18:29:24 UTC
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.
Comment 16 Pedro V 2023-11-18 11:44:05 UTC
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.
Comment 17 Sergio 2023-11-19 10:50:31 UTC
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.
Comment 18 baltic 2023-12-04 06:47:20 UTC
(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.
Comment 19 baltic 2023-12-04 06:50:51 UTC
(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.
Comment 20 Marco Schmidlin 2024-04-22 06:30:57 UTC
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
Comment 21 Marco Schmidlin 2024-04-22 06:51:49 UTC
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 :)
Comment 22 Bug Janitor Service 2024-04-25 13:46:14 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4263
Comment 23 Marco Schmidlin 2024-04-25 16:45:23 UTC
(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?
Comment 24 Natalie Clarius 2024-04-25 16:52:42 UTC
(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.
Comment 25 Natalie Clarius 2024-04-25 17:17:19 UTC
(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.
Comment 26 Bug Janitor Service 2024-05-23 02:00:42 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/powerdevil/-/merge_requests/363
Comment 27 Bug Janitor Service 2024-05-23 02:04:37 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4341