search

linrunner / TLP

TLP - Optimize Linux Laptop Battery Life
https://linrunner.de/tlp
GNU General Public License v2.0
2.74k stars 130 forks source link

ACPI wakeup trigger filtering #620

Closed drws closed 2 years ago

drws commented 2 years ago

Is your feature request related to a problem? Please describe.

TLP could provide an option to set ACPI wakeup triggers in /proc/acpi/wakeup on startup and monitor them later. Some of the triggers may be unwanted or can prevent some systems from sleeping and can thus have a great influence on power management.

Describe the solution you'd like

Ideally one would be able to enable or disable individual triggers, but disabling (preventing wakeups) is of primary concern. The latter could be achieved by adding one option to TLP configuration containing the list of to-be-disabled wakeup sources while the complete solution would provide two options (a blacklisting and a whitelisting one).

Describe alternatives you've considered

Manual scripting is always an option. PowerTOP also provides such options. But I think it could be a very welcome addition to TLP.

linrunner commented 2 years ago

In fact, I have already considered this feature myself.

What stopped me is the complicated configuration. That is: how do I explain to the user how to find out which of the cryptic entries in /proc/acpi/wakeup is the right one for his use case.

If you don't have a really ingenious suggestion, there will be no implementation.

drws commented 2 years ago

/proc/acpi/wakeup wakeup trigger IDs are in fact a bit more cryptic than standard Linux device names, but on the other hand they are at least short and seem to uniquely represent different types of wakeup sources. But /proc/acpi/wakeup also provides sysfs PCI IDs, so there is another way to address wakeup triggers, even already used by some TLP configuration options. PCI IDs also provide a way for users to explore each source manually, again similar than with other configuration options such as RUNTIME_PM_ ones.

Also please take a look at how PowerTOP parses wakeup sources. The resulting short device names seem useful to avoid the cryptic wakeup trigger names.

linrunner commented 2 years ago

If you want to have this you have to implement it yourself, e.g. pull request including docs.

drws commented 2 years ago

You seem to be a bit on and off about the issue. At first you said you were thinking about it yourself and that we should discuss, but slapped a rejected label on it. Not a problem, that is the current status of the issue after all. But when I put down some starting points you in response only closed the issue and told me I can implement it myself while literally not saying anything else. Well, yes, but we both knew that even before I opened the issue.

Regardless of who works on the issue it would be helpful if you first answered/commented on proposals from earlier discusson, namely:

I've solved this issue with a systemd startup service a while ago. Fortunately my system doesn't reset the triggers while traversing different power states so the "rules" only need to be applied at boot. And the systemd service could easily be extended to cover that as well. When I have more time available, I'll be investing it in open-source development and TLP sure seems like a great candidate. But when I do, firstly there's a similar story with you not wanting to discuss #281 that I need to get marked as closed in my book as well.

linrunner commented 2 years ago

In fact, over the many years I've got quite picky concerning feature requests. Chances depend on how many users it could be interesting for and how high the potential cost of researching the implementation path, implementation and testing is. Besides, tlp.conf is already quite long and I don't want to extend it with niche features.

I have neither time nor motivation to write long justifications. Concerning your previous feature requests my assessment is:

By the way, I've in fact in the past included features that I didn't really want to include. Simply because someone submitted a well-developed pull request.

For your proposal here, I see potential for a small to medium number of users. However, the configuration must be dead simple and very well described. You are welcome to risk a pull request. Closed and rejected in this case only means that I will not work on it myself.

What I don't want to include is a new systemd service. Many distributions refuse to enable services during package install. This makes the installation instructions longer and longer, and "smart" users think they don't have to activate the service at all.

By the way, I don't expect that there are systems that reset the triggers when the power source is changed. But feel free to implement provisions for this.

drws commented 2 years ago

In fact, over the many years I've got quite picky concerning feature requests.

I get it and I think you should be, but I also think this is a good one for TLP (and not niche like #281). You said yourself you were thinking about it and the showstopper is somewhere else.

As for #281, I acknowledge my input is needed as well, but I pointed out the fact you closed and rejected it before we could even properly discuss possible solutions, so I put it on my backlog.

As for #619, I didn't mention it because it is the only one finished. I outright started its description with the fact that it is out-of-scope, you rejected it and did not mention wanting to discuss concrete implementations. I tried to initiate a conversation and when that didn't work I guessed it was finished. I don't know why you brought it up.

The assessment itself is useful, but not to the issue. It's more of a private-message material.

"smart" users think they don't have to activate the service at all

I don't think this is an issue. Those will always find a way to cripple functioning software and there will always be something more to be done for ignorant users. I'm also not sure why would an additional service be needed when TLP could handle everything as is handling everything else?

Regarding the issue:

Upon further inspection I found out that PowerTOP only reads wakeup triggers for networking and USB devices through /sys/class/net and /sys/bus/usb/devices. That only covers a part of available wakeup triggers and only complements /proc/acpi/wakeup. The easiest way to find all sysfs wakeup triggers is to look through /sys/class/wakeup directory.

When putting down all of my findings to post here a new ArchWiki page came out of it instead. I've collected all the info I could find and supplemented it with my own findings there, so it should be useful for anyone interested.