Integrate system76-power settings into gnome-control-center

[brs17]

Related Application and/or Package Version (run apt policy $PACKAGE NAME):
system76-power
gnome-shell-extension-system76-power

Issue/Bug Description:
The settings currently only available via gnome-shell-extension-system76-power should also be available in gnome-control-center. This is the first step in supporting configurable power profiles.

[mmstick]

Functioning prototype:

[ayoungethan]

I have some further optimization suggestions for the performance power profiles, to both simplify and streamline them and also help them cover a wider range of usage scenarios, including low latency priority and low latency throughput priority.

Should I put those suggestions here or in a separate bug report?

[ayoungethan]

https://pop-planet.info/forums/threads/power-management-design-interface.739

also, see deinstapel/cpupower#14 as they are interested in expanding the functionality of their already-excellent extension. There is some overlap that might translate to collaboration.

[yochananmarqos]

This is already being worked on upstream, see: https://www.phoronix.com/scan.php?page=news_item&px=GNOME-power-profiles-daemon

[ayoungethan]

This is already being worked on upstream, see: https://www.phoronix.com/scan.php?page=news_item&px=GNOME-power-profiles-daemon

thanks for sharing. it looks like they are replicating the same mistaken belief that the 3rd power profile, "power saving" actually saves power. it does not, in most cases, because it violates race to sleep, which is why "balanced" is appropriate for the vast majority of use cases. the remaining use cases will benefit from having a tuned "performance" setting. "power saving" really shouldn't exist except for a few niche cases, and should be renamed "low heat" or "low noise" because ultimately that is what it accomplishes.

the idea that throttling a cpu saves power or battery life really needs to die. it just keeps a cpu in a less efficient active state for longer, which is only good for niche cases that need to manage the thermal envelope or noise under load at the expense of overall efficiency. that is why Mac OS has better battery life - it embraces race to sleep design principles.

[yochananmarqos]

@ayoungethan I've been researching this a little today and I agree. I created a udev rule to set the Balanced profile on battery and Performance on AC for now.

[ayoungethan]

@yochananmarqos it seems like retreading over the original debate between the "ondemand" and "powersave" ACPI software performance governors before that functionality was moved over to hardware. Limiting max CPU frequency in the age of frequency scaling is really niche (and I am speaking from the perspective of someone who has use for that niche -- when doing low latency audio recording, I don't need a lot of CPU performance, but I need stable low-latency, low-jitter performance and ideally minimal fan noise and thus heat generation, which means locking the CPU at a lower-ish stable frequency on top of performance tuning to give the audio subsystem high priority, eliminate the overhead of symmetric multi-threading, etc).

Perhaps what is most missing, I think, is an integrated power management API that requires that an (or at least allows developers to easily ensure that their) application conforms to a "race to sleep" standard set by the OS developers. To my very limited knowledge, Mac OS really pioneered this. I haven't been keeping up to date on things, though, so maybe someone is working on this already...!

[hadess]

it looks like they are replicating the same mistaken belief that the 3rd power profile, "power saving" actually saves power

FWIW, I replied to this in:
https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/issues/21#note_851091
In short, "race-to-idle" solves a different problem from "I want my laptop to still have battery in an hour".

You can find here my attempt at breaking down what system76-power does and seeing what can be done in the vanilla kernel, or would still require tweaking:
https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/issues/26#note_1021525

If you want to keep your own profiles daemon (it's written in Rust, that's already better than what I'm using), maybe having it implement the power-profiles-daemon D-Bus API would be the best course of action, though mimicking its behaviour (like remembering the profile across reboots) might be a bit harder.

Ideally though, all the tweaks you have would be available in the vanilla kernel, or exported in your machines' firmwares through to the kernel through the platform_profile API.

Don't hesitate to reach out if you have any questions or want to discuss this in a higher bandwith setting.