Add devices to disable for power saver, decoupleing balanced and powersaver#892
Add devices to disable for power saver, decoupleing balanced and powersaver#892dusklinux wants to merge 3 commits into
Conversation
|
Thanks in advance. I'm busy right now, but I'll check back when I have time. |
|
No problem. The code base was well written, and required only surgical edits because the groundwork was already laid out. I only added ~38 liines using the same logic you already had in place. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
This approach isn't complete yet, the topic is more complicated. When switching from balanced to power-saver profile, the radios listed in |
|
That's interesting, I'll re-test to make sure it works, and push the commit where it needs fixing. |
|
We'll need a In addition, the fallback Finally, I'd like to consolidate the sections in tlp.conf; otherwise, it will become overwhelming. I'll do that myself once functionality is finished. |
…S_TO_ENABLE_ON_BAT/SAV
|
I have updated the pr to address your feedback: Added DEVICES_TO_ENABLE_ON_BAT and DEVICES_TO_ENABLE_ON_SAV to give users explicit control over enabling specific devices when transitioning back to the balanced profile. Removed the fallback behavior between _BAT and _SAV configuration options, making the profiles completely independent. Updated tlp.conf.in with documentation for the new variables and removed fallback descriptions. I have tested transitions between all profiles (performance, balanced, power-saver) on my system, and the devices now enable and disable correctly. I made sure to have it match the naming scheme that you already had in place. I spent the last two hours figuring it out and fixing it. I've stress tested it every whichway, rest assured it works well now. |
|
Great. I'm still working on something else right now. I'll take a look at it after that. |
|
Alright, I wont hold my breath, |
|
@dusklinux will tlp setup be re added to dusky after this is merged? |
|
Yup. |
|
Your code works. I merged it externally, not here on the platform. Please make sure in the future that there are no “commit accidents” in the history. A Before this goes to main, I’ll make some additional changes:
When someone points out an issue to me, I sometimes spontaneously come up with further ideas... Stay tuned! |
|
Perfect! Sounds great! I'll keep that in mind. |
|
Testing of course. |
|
Anytime. Just let me know when, and provide a link to the project with the updated logic. |
|
I would like to point out that two different things are being mixed here. Namely the energy source BAT/AC and energy profiles SAV/BAL/PRF, which can be configured for each regardless of the energy source. DEVICES_TO_DISABLE_ON_BAT/AC and DEVICES_TO_ENABLE_ON_BAT/AC would therefore have to be completely replaced by ON_SAV/BAL/PRF |
Yes, I only figured that out after the fact, you're entirely correct and great catch! |
Standardize parameters for all profiles: * DEVICES_TO_ENABLE_ON_AC * DEVICES_TO_DISABLE_ON_AC (added here) * DEVICES_TO_DISABLE_ON_AC_NOT_IN_USE (added here) * DEVICES_TO_ENABLE_ON_BAT (added previously) * DEVICES_TO_DISABLE_ON_BAT * DEVICES_TO_DISABLE_ON_BAT_NOT_IN_USE * DEVICES_TO_ENABLE_ON_SAV (added previously) * DEVICES_TO_DISABLE_ON_SAV (added previously) * DEVICES_TO_DISABLE_ON_SAV_NOT_IN_USE (added previously) * DEVICES_TO_ENABLE/DISABLE_ON_STARTUP will remain, but the profile-based ones will take precedence if both are configured. Misconfigurations: devices that appear in both the enable and disable lists will be ignored when switching. Discard the workaround for reactivating wifi during shutdown (X_WIFI_ON_SHUTDOWN). It became redundant due to the NM-based switching introduced in 1.9.0. Make the workaround for restoring the bluetooth and wwan state after a suspend/resume cycle optional; it now requires X_TLP_SUSPEND_RFKILL_PERSIST=1. References: * #891 * #892
|
@dusklinux unlike my announcement above, I left @Mylinde Back when profiles were introduced in 1.9.0, I was already aware of the dilemma of parameter suffixes vs. profiles. However, I had to weigh two risks against each other. We can certainly discuss this, because action is needed. Just please don't do it here in this PR. |
|
This appears to a be a much better implementation on first glance, Will be testing this extensively by tomorrow at the latest. Will be sure to provide any feedback, negative or positive. |
No description provided.