This mirrors the behavior used by Kernel 6.5 and later where amd-pstate
is configured to default into 'performance' by the kernel. It's not
as useful in server to be changing it.
Link: 32f80b9adf
Drivers can be blocked from loading via `POWER_PROFILE_DAEMON_DRIVER_BLOCK`
which is a comma separated value listing the drivers to block.
This is an escape hatch in case CPU or platform driver are failing and a user
would like to block them.
The "cool" profile isn't a low-power mode, but a mode where the fans are
always running to reduce the temperature, presumably to allow it to run
faster.
At the same time, we need to handle the lack of low-power profile on HP
machines as they only had a cool mode and no low-power mode.
Closes: #89
WARNING: You should add the boolean check kwarg to the run_command call.
It currently defaults to false,
but it will default to true in future releases of meson.
See also: https://github.com/mesonbuild/meson/issues/9300
If we are to run all the tests in parallel, we need to make sure that
each instance of the daemon gets its own configuration file, otherwise
all of them will be trying to change each other's config behind their
backs.
Remove restoring the problem from the on-disk kernel file, as was done
for the platform_profile, as we want to implement actual persistence
across reboots.
We need to be the ones saving that data, as the kernel doesn't know
whether the profile changes are temporary, or permanent, and whether the
user was the one initiating that change.
The PerformanceInhibited property was there to convey that the
performance profile was unavailable, and that the daemon should switch
to a lower profile to avoid using the performance profile.
But it was difficult to communicate whether the daemon should switch
back to the performance profile when the inhibition disappeared, or
whether it should keep the same profile (the latter was what was
implemented).
There was also the problem that depending on the backend, the
performance profile might be able to provide a behaviour that wouldn't
match either of the unhampered performance profile, or the balanced
profile, but somewhere in between.
The PerformanceInhibited property is kept for compatibility reasons with
the existing consumer, GNOME 40. It will be removed in the future and
should not be relied on.
Closes: #24
Because of the way gnome-shell's animation framework is built, setting
energy_performance_preference to balance_power has a visible impact
on the smoothness of animations, as the CPU will clock down too quickly
between frames, leading to the appearance of a performance regression.
Disable the on-battery behaviour until gnome-shell is fixed to avoid
being accused of slowing systems down.
See https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/issues/28#note_862766
Which allows us to ignore trailing spaces in the sysfs attribute, as
power-profiles-daemon writes those mock files without a linefeed, but
the real kernel (or some of our setup functions) would always append
a linefeed.
Of all the drivers that we've implemented, not a single one needed to
have different drivers to handle its different profiles, so simplify
things by having all the profiles be handled by a unique driver.
We still have separate drivers for separate types of hardware.
