tuned-ppd: Detect battery change events

[superm1]

power-profiles-daemon has the ability to detect battery change events using upower and to apply different tuned settings based upon whether plugged into power or not.

In PPD this is used specifically to set the energy performance preference differently in the 'balanced' profile, but there is no reason that this concept can't actually apply to all profiles.

Add support for detecting battery change events and apply a profile specified in ppd.conf for battery in the different PPD states.

CC @smallorange

[zacikpa]

Thanks for the PR, @superm1.

I'm a bit confused about the motivation behind this update. As I understand it, it's currently the users of ppd who choose to switch the ppd profile if the system changes from battery to AC or vice versa. For instance, gnome switches to the power-saving profile (using a hold) when below a certain battery level and the system is unplugged from AC. Can we be sure that this new extension won't cause any conflicts with the existing behavior of ppd/tuned-ppd users?

[superm1]

Sure let me explain the background of it. The PPD daemon does use upower to monitor for battery changes and some "PPD drivers" will react to this and make changes "within" their given profile. GNOME and KDE aren't notified over D-Bus when this happens. It's all internal to PPD.

The reason for bringing this functionality to tuned-ppd is so that when a distro changes to tuned and tuned-ppd the power consumption on battery doesn't go up.

[superm1]

Sorry I realized I didn't answer your question. In terms of what GNOME does at low power (at least with PPD) it's tangential.

I think it's best to think of it as a "subprofile" for a given profile.

[zacikpa]

Sorry I realized I didn't answer your question. In terms of what GNOME does at low power (at least with PPD) it's tangential.

I think it's best to think of it as a "subprofile" for a given profile.

Thanks for the explanation. I'm also wondering whether the dynamic part of #601 shouldn't also be moved here, as part of the "subprofiles".

[superm1]

Sorry I realized I didn't answer your question. In terms of what GNOME does at low power (at least with PPD) it's tangential.
I think it's best to think of it as a "subprofile" for a given profile.

Thanks for the explanation. I'm also wondering whether the dynamic part of #601 shouldn't also be moved here, as part of the "subprofiles".

Yup; that was already on my mind. If this one gets accepted first I'll modify that one. If that one gets accepted first I'll modify this one.

[zacikpa]

Thanks for the update. Do I understand it correctly that power-profiles-daemon does not change its profile set when on battery? If so, I'd enforce that here as well, as suggested in one of the comments.

[superm1]

Thanks for the update.

👍

Do I understand it correctly that power-profiles-daemon does not change its profile set when on battery? If so, I'd enforce that here as well, as suggested in one of the comments.

Sounds good. I've made that change and your other suggested ones.

[superm1]

Yup; that was already on my mind. If this one gets accepted first I'll modify that one. If that one gets accepted first I'll modify this one.

I've made the changes to plugin_video on another branch that has both PRs merged to stop using upower and to instead have the separate profiles for balanced vs balanced-battery. It works well. Here is what that diff looks like: 30dc23a

[zacikpa]

Thanks, looks good. Just two more nits.

[zacikpa]

Perfect, LGTM.

I think the cleanest solution now would be to adjust #601 (keeping just the new video plugin option), and split this PR into two commits, one adding the battery functionality, the other updating ppd.conf with the new battery profiles.

Btw, is panel_power_savings=0 the default value? If yes, I think we don't need to add it to existing profiles at all.

[superm1]

Btw, is panel_power_savings=0 the default value? If yes, I think we don't need to add it to existing profiles at all.

What does default mean? I want to make sure that no matter what value it is set before starting tuned that it gets corrected to 0 if balanced.

[zacikpa]

Btw, is panel_power_savings=0 the default value? If yes, I think we don't need to add it to existing profiles at all.

What does default mean? I want to make sure that no matter what value it is set before starting tuned that it gets corrected to 0 if balanced.

Oh, right, that makes sense.

[zacikpa]

LGTM.

[yarda]

LGTM, thanks.