When I configure my system to suspend after, say, 15 minutes of inactivity, then that’s what it’ll do, even when stuff is still happening on the system. It might be down- or uploading a bunch of data or running some kind of computation. Usually when I do that sort of thing, I don’t want the machine to suspend until it’s done.
How about we add optional, configurable thresholds for CPU/GPU/network activity in the energy settings, and as long as there is any activity above any of the configured the thresholds, suspend is inhibited? I know that applications can inhibit suspend themselves, but they don’t always do (think of some one-off script you might have written yourself), and while this proposed mechanism wouldn’t cover all imaginable scenarios, I think it would be a simple solution that does the job most of the time.
You have a button for to inhibit the automatic suspend and screen locking in the Power tab of the tray.
You have a dbus service that you can use in inhibit suspension so you can script it.
Video players use it for instance.
That’s a double edge sword, the level of activity might not be great. An idle game or some video in a loop could still use a big chunk of GPU resources, but is a case when suspension makes a lot of sense.
This is already manually and programmatically editable, use it, no need for a toggle for a particular use case that can easily work with it.
I am aware of that, but I’m afraid you’ve missed the crucial point in my suggestion. I said I don’t want the machine to suspend until it’s done. Inhibiting suspend manually doesn’t serve the purpose of keeping the machine alive until it’s done with whatever job I left it running for, and then having it suspend.
I am aware of that as well. In fact I wrote:
I’ve proposed this specifically in order to deal with the fact that we don’t live in an ideal world where every application that should do this does. You can argue that it’s the applications that need to implement this, but I think that dealing with poorly written applications as best as possible is part of being a good operating system. Think of things like protected memory or how Android often refuses to run applications in the background to preserve energy.
I think that the fact that resources are being utilized is a reasonable proxy to indicate that some useful work is being done, hence the suggestion. Those who agree with me can use this, and those who don’t don’t. Not every feature is for everybody.
“You can script this yourself” is never the answer when the goal is to create a user-friendly operating system. Most users don’t know how to write scripts, and of those that do, many (most?) aren’t aware of the inhibition thing, and of those that remain, many (like me) just can’t be bothered. I’d much rather have a simple, declarative solution that does something reasonable 95% of the time.
Yes, but it depends for what.
The manual toggle good for 99% of users.
Having this particular feature does not make Plasma any more user-friendly, I’d argue the opposite. An obscure setting is dead weight for most users, this complexifies Plasma for a very very niche use case. That’s somewhat debatable, but you can admit most users will never ever have a use for this.
Where a feature is too niche, the system is meant to be flexible, once you have a script you can make a UI out of it, never have to deal with it. And link it to measurements or other things.
And given you use your gpu for some compute you definitely are in the “more advanced” user category.
Then you can make a .desktop that uses it and launch it with a shortcut through menus…
And applications can themselves toggle suspend inhibition as video players do.
You can report this issue to the application maintainers, so this can be toggled precisely as the critical process is running and disabled afterwards.
I assume this number is based on an empirical study with a significant amount of representative users? Because otherwise I’d have to conclude that you just made it up in order to justify your personal dislike of the proposal.
Your use of denigrating language like “obscure” once again demonstrates motivated reasoning. But things like downloading a game on Steam are just about as far away from a “niche use case” as it gets, and it’s currently not handled well. I have the choice of either inhibiting suspend, leaving the machine running for longer than it needs to, or forgetting about it entirely and then waking up to the fact that whatever I had left the computer running for is still not done.
No, in fact I’d argue the exact opposite: it’s the current implementation that most users don’t have a use for. Why would I want the OS to suspend my machine even when it knows that work is being done right now? Computers don’t usually consume resources for no reason, but because they’re doing some work on behalf of the user.
Notice also that the failure mode for this proposed feature is quite benign: your computer might consume a little bit more energy once in a while (even most laptops are plugged in most of the time, and when you’re on the go, you’ll probably just shut the lid when you’re done, triggering suspend that way). On the other hand it’s quite annoying to find that the job you had started isn’t done because the OS thought it was more important to save 5 cents worth of electricity
I’m not sure which one confuses me more: the idea that using the hardware that I bought makes me an advanced user, or the idea that advanced users don’t deserve features that make their lives easier.
While the topic is totally foreign to me (primarily because my laptop system does not sleep on inactivity), I would like to admit that:
there are many users which session is defaulting to “sleep” on idle;
there are also many users (like me) that start some urgent background work like downloading film/game, continue to work with something else and at some point they simply move away from the workplace for a fairly long period of time, forgetting about this inhibitor switch.
As long as the possibility of such an unpleasant scenario exists, I cannot consider the problem to be “niche”. From the other side, I somewhat agree with @meven regarding the cluttering of system settings, so without knowing the optimal solution for such a problem for most users, I would not put this in the system settings (at least in the main ones).
I found a similar discussion for Windows 7, where the author was advised to use third-party software for these purposes. I think development of such thing on top of something like this shouldn’t be a very challenging task. The most hard part is to provide such facilities that will allow such a service to be flexible to meet the needs of the majority of users, otherwise the solution will really be “niche” and only interfere with the user.
the problem i see with this feature being usable is misconfiguration of any/all of those and yet still having the machine suspend when you don’t want it to, or not suspend when you do.
i mean what is the right threshold? you would have to decide that in advance without any idea what the real value is for a given operation
and if you get it wrong, then it will suspend anyway because it didn’t rise to the level, or never suspend because normal background activity is keeping it awake.
this would also be a nightmare to troubleshoot for those who come here asking “why won’t my machine suspend?”
i agree with this statement, the manual toggle meets my needs… and is easily diagnosed by checking the widget in the system tray.
at the point where you start an urgent task that you cannot afford to have interrupted, that’s when you toggle the inhibit.
there is no way for the OS to know what the user considers urgent, unless it is told.
perhaps a better feature request would be some way for the user to tell the OS that this task/process must not be interrupted, therefore suspend should wait until it’s done.
one toggle for the whole system seems like a blunt tool.
This is exactly where the disagreement lies, because the premise behind this feature proposal is that there is in fact a reasonable heuristic: when there’s a lot of CPU load or network activity, the system is probably doing something that the user wants to get done. Is that a perfect heuristic? Of course not! But let’s not forget that the current logic, i. e. “suspend when the user hasn’t touched their mouse and keyboard in 10 minutes”, is also a heuristic, and, I would argue, one that’s worth improving.
systemd-inhibit can be used to achieve this for a single command, but that requires that process to end when it’s done, which is not the case for interactive applications.
Just to give a few examples:
neither Firefox nor Chrome inhibit suspend by default when downloading a file
even if you have the Plasma integration extension, Chrome doesn’t enable it by default in private browsing mode, so it doesn’t work in that case
Steam doesn’t inhibit suspend
Blender, as an example of a CPU and GPU intensive application, doesn’t inhibit suspend by default
So I think it’s pretty clear that in the real world, we can’t rely on applications to do this. Inhibiting suspend manually is in my opinion pretty far from a satisfying solution for two reasons:
it doesn’t allow the system to suspend once it’s done with the job, defeating the point of auto-suspend
it requires the user to foresee a possible failure mode – the system suspending even though it’s busy – and then take action to prevent it using a knοb that they might not even know exists
This last point is actually the more important one, because users really have much more interesting things to think about than their machine’s energy policy. But overly simplistic heuristics like “suspend when the user hasn’t pressed a button for 10 minutes” force them to, and I think we can do better.
monitoring Human Interface Devices (HID) is and excellent and time tested way to tell if the machine is actively being used by the user… questioning this is a stretch.
you give examples of several highly used and popular applications that have not implemented an inhibit… ask yourself why that is.
again, i would ask you what is the threshold for “a lot of CPU load or network activity”… seems to me there is no good answer to this, which is why you didn’t provide one.
A solution isn’t good just because it’s been around for a long time, which is all that “time tested” really means. In fact it’s precisely because this heuristic doesn’t work very well in practice that we have both programmatic interfaces and UI knοbs to work around it when it goes wrong.
By that logic, no highly used and popular application ever needs any new feature, because the fact that it doesn’t have it yet serves as proof that it isn’t necessary.
The reason it wasn’t implemented is simple: their developers are busy and they have bigger fish to fry. The KDE community clearly does consider it useful because they have implemented this functionality in the Plasma integration extensions. But Steam doesn’t support extensions, and more generally, I think it’s futile to wait for an ideal world where all applications support these interfaces – that world will never come.
Your reasoning doesn’t convince me because it’s essentially a cop-out: we can’t figure out if the right threshold is 10% or 50% CPU load, and because we’re so afraid of not getting it right, we end up going with the equivalent of a 100% threshold, which is certainly not the right number.
Again, it’s not about finding a perfect solution because that doesn’t exist – it’s about finding something that works better than the current state of affairs, and that doesn’t seem impossible.
Again app can handle it for the benefit of the users, video players do, bittorrent client can do it. ktorrent does it for instance. Or many Plasma process do it, like file operations.
That’s the best option possible, fine-grained, automatic, no configuration, cross-DE.
Report this as feature requests to the concerned apps is my best advice.
And there are are even more applications that haven’t done this, don’t do it, and won’t do it, but users will will continue to use them for one reason or another.
x2: there will always be applications (and most “regular” users have many such applications) for which such a thing as “report” is not applicable. I agree, it sounds incredible, but: not everything is open source, not everything is open to suggestions, not everything continues to be supported, not everything is fleeting. And as long as the user has a need to “tweak” behavior from the outside, this is a worthy reason. No excuses about vague heuristics and “the best solutions”.
Unfortunately, conversations on this topic will give a little. Primarily because of wrong posing the question: there is no reason to include such a feature in the functionality of Plasma system components, however, as well as furiously reject the very need for such a feature, believing that we are necessarily talking about its inclusion in system components.
The only advise I can give to @mberndt123 is to focus on the existing solutions (e.g. I mentioned earlier) and try to rework it prior to his needs with an eye on potential other users. I repeat, implementing such a service and the UI for it does not look like a difficult task (most likely it is not). The question is whether there is a developer interested in this. And if you are able to write code, it worth to try yourself. Maybe the result of your efforts will be in demand among users; this fact may be sufficient grounds for a second debriefing.
they do not use an inhibit because their users don’t need it… the HIDs those applications rely on are sufficient for their users to prevent the machine from suspending on them while they are trying to do their work.
their “old way” of doing things just works and doesn’t require improvement.
you could also try setting your suspend timer to a long enough period so that your average forgotten background task will complete before the timer runs out.
No, you missed the point: users need it, as evidenced by the fact that the Plasma integration extensions for Chrome and Firefox do implement it. There’s no reason to assume that this makes sense for a download in Firefox, but not for a download in e. g. Steam.
Again, it manifestly doesn’t “just work” because if it did, we wouldn’t need either UI controls or D-Bus interfaces to disable it. It’s unfortunate that you choose to double down on this point despite this.