More tuned-ppd adjustments #669
Conversation
zacikpa
force-pushed
the
ppd-adjustments
branch
from
699c5a2 to
673ae32
Compare
|
CI failures fixed. |
zacikpa
force-pushed
the
ppd-adjustments
branch
from
673ae32 to
e0ed8b3
Compare
|
Rebased onto master because the issue resolved by the first commit was fixed by c082797. |
|
Added another change - a new |
zacikpa
force-pushed
the
ppd-adjustments
branch
from
6acb2da to
cb4a882
Compare
|
Moved the first commit into a separate PR: #697. That one should ideally land in Fedora 41 before the final freeze. The rest are more complex and will likely require some discussion. |
|
Just chiming in here to say that technically this is api-incompatible still with PPD. The original PPD cannot return an This can cause a crash in gnome-control-center: see https://bugzilla.redhat.com/show_bug.cgi?id=2324518. Now, I don't really see a way around this, but it would be good to document this. Source: I'm the upstream (co)maintainer of gnome-control-center. |
|
Thanks, @velsinki. I'll adjust the code not to perform this check. |
|
Thanks for the reply. I'm not sure that's ideal either, as it would mean tuned-ppd is lying about which profile is active? We'll anyways fix the crash in gnome-control-center, not against keeping "unknown". I don't know what other consumers of PPD are doing though, GNOME Shell should have a similar issue. |
Exactly. I agree it's not ideal, but it shifts the responsibility to the users when they mess with the TuneD profiles via multiple methods. What's your proposed behavior of gnome-control-center if tuned-ppd returns "unknown"? It would certainly be nicer if we could keep the implementation as it is now. I would check with the other users of PPD to see whether they would be able to deal with it too. |
We currently show three radio buttons (performance, balanced, power-saver). If tuned-ppd would lie about a profile, we would start the UI with that radio button enabled, as we don't know anything else. That would mean that radio button can't actually be clicked anymore, as it's already active. If however we get "unknown", we can start the UI with no radio buttons selected instead. Currently we don't handle "unknown", and crash, but that's not hard to support. |
This sounds like very reasonable behavior.
In that case, I'd prefer to keep this as is and check in with the other consumers. Sorry for the troubles and thanks for looking into this! |
|
It would also be nice if the tuned profile is tracked, and if it changes, tuned-ppd anounces an ActiveProfile property change. That would resolve #689. |
zacikpa
force-pushed
the
ppd-adjustments
branch
11 times, most recently
from
9768c01 to
734cb53
Compare
Make sure that we only initialize the UPower signal handler only if such a handler is not already running. This also reorders the order of operations in the initialization procedure, skipping redundant initial TuneD profile changes.
zacikpa
force-pushed
the
ppd-adjustments
branch
from
734cb53 to
39f9651
Compare
Instead of querying TuneD each time we want to determine the active TuneD profile, remember its value. Also watch for signals from TuneD, updating the value when the TuneD profile changes (resolves redhat-performance#689). The daemon now also keeps track of the "base" PPD profile, which is restored when all profile holds are released or when tuned-ppd is restarted. For the latter purpose, this profile is also saved in a file. Direct access via two dictionaries (one for AC, one for DC) was clumsy, this commit replaces it with a new class - ProfileMap.
This makes tuned-ppd fully API-compatible with the latest power-profiles-daemon. The property will signify the level of API compatibility with power-profiles-daemon.
To be consistent and make sure tuned-ppd works well with its users no matter the configuration, the balanced profile must be required in the configuration file, similarly to the power-saver and performance profiles. If no default profile is specified in the configuration, this also sets the default profile to balanced, not raising any exceptions like before.
Instead of actively polling for changes in the relevant files, set up inotify handlers which are invoked when the files change.
On some Thinkpad laptops, it is possible to change the ACPI platform profile using function keys (e.g., Fn+L). This can now trigger a complete profile change if the functionality is enabled. Resolves redhat-performance#710.
zacikpa
force-pushed
the
ppd-adjustments
branch
from
39f9651 to
23eb673
Compare
|
Major update pushed now:
|
Tuned has become the new default in Fedora 41, replacing PPD. Tuned does offer the same DBus interface with tuned-ppd. However, because tuned supports much more profiles, the tuned-ppd api is slightly incompatible as it can return an "unknown" active profile. Some discussion here: redhat-performance/tuned#669. This crashes the Power panel. Instead, let's handle this by not doing anything when we get that profile. This means no radio buttons will end up getting selected, but that's better than showing an active profile that isn't really active. Note that tuned-ppd currently does not actively announce an ActiveProfile change if the change came from tuned, but it might start to in the future, so We do this by adding a new enum value, outside of the range of actual profiles, as we don't want to handle it as a real profile anywhere. This also removes the manual enum counting, there's no reason for that as enums are guaranteed to start at 0 and increment by 1. Note that tuned-ppd currently does not actively announce an ActiveProfile change if the change came from tuned, but it might start to in the future, so also reset all radio buttons if we get an unknown profile, just in case someone has the Power panel open and changes the active profile via tuned. (cherry picked from commit 131c559)
Tuned has become the new default in Fedora 41, replacing PPD. Tuned does offer the same DBus interface with tuned-ppd. However, because tuned supports much more profiles, the tuned-ppd api is slightly incompatible as it can return an "unknown" active profile. Some discussion here: redhat-performance/tuned#669. This crashes the Power panel. Instead, let's handle this by not doing anything when we get that profile. This means no radio buttons will end up getting selected, but that's better than showing an active profile that isn't really active. Note that tuned-ppd currently does not actively announce an ActiveProfile change if the change came from tuned, but it might start to in the future, so We do this by adding a new enum value, outside of the range of actual profiles, as we don't want to handle it as a real profile anywhere. This also removes the manual enum counting, there's no reason for that as enums are guaranteed to start at 0 and increment by 1. Note that tuned-ppd currently does not actively announce an ActiveProfile change if the change came from tuned, but it might start to in the future, so also reset all radio buttons if we get an unknown profile, just in case someone has the Power panel open and changes the active profile via tuned.
Tuned has become the new default in Fedora 41, replacing PPD. Tuned does offer the same DBus interface with tuned-ppd. However, because tuned supports much more profiles, the tuned-ppd api is slightly incompatible as it can return an "unknown" active profile. Some discussion here: redhat-performance/tuned#669. This crashes the Power panel. Instead, let's handle this by not doing anything when we get that profile. This means no radio buttons will end up getting selected, but that's better than showing an active profile that isn't really active. Note that tuned-ppd currently does not actively announce an ActiveProfile change if the change came from tuned, but it might start to in the future, so We do this by adding a new enum value, outside of the range of actual profiles, as we don't want to handle it as a real profile anywhere. This also removes the manual enum counting, there's no reason for that as enums are guaranteed to start at 0 and increment by 1. Note that tuned-ppd currently does not actively announce an ActiveProfile change if the change came from tuned, but it might start to in the future, so also reset all radio buttons if we get an unknown profile, just in case someone has the Power panel open and changes the active profile via tuned.
TuneD provides a compatibility daemon (tuned-ppd) which replaces power-profiles-daemon in Fedora 41 [1]. However, the new daemon can report an "unknown" profile in case the user manipulates with underlying TuneD profiles directly; see [2]. Before this change, the "unknown" profile makes the battery applet panic. With this change, the applet reports the balanced profile. This is in line with the behavior of cosmic-settings [3]. [1] https://pagure.io/fesco/issue/3222 [2] redhat-performance/tuned#669 [3] https://github.com/pop-os/cosmic-settings/blob/6f05e9e/cosmic-settings/src/pages/power/backend/mod.rs#L65
TuneD provides a compatibility daemon (tuned-ppd) which replaces power-profiles-daemon in Fedora 41 [1]. However, the new daemon can report an "unknown" profile in case the user manipulates with underlying TuneD profiles directly; see [2]. Before this change, the "unknown" profile makes the battery applet panic. With this change, the applet reports the balanced profile. This is in line with the behavior of cosmic-settings [3]. [1] https://pagure.io/fesco/issue/3222 [2] redhat-performance/tuned#669 [3] https://github.com/pop-os/cosmic-settings/blob/6f05e9e/cosmic-settings/src/pages/power/backend/mod.rs#L65
This PR brings another round of tuned-ppd adjustments and bug fixes. The individual commit messages explain why the changes are being made.
The most prominent change is dropping reverse profile mapping, i.e., from TuneD to PPD profiles. Instead, the daemon now keeps track of the currently active profile and the so-called base profile. This improves tuned-ppd in two ways: