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.
Make it possible for programmes to temporarily change the current
power profile, and "hold" that profile while they're performing a
task or waiting for an event to clear. This would be useful for:
- programmes with a finite workload to finish faster by investing more
energy resources (eg. compiling software or transcoding media)
- programmes with near constantly high workloads to avoid the costs of
transitioning between hardware profiles and causing stutters such
as games or 3D modelling programmes
- OS components to force power-saver mode while battery energy is
at a premium
Closes: #11
Co-Authored-By: Bastien Nocera <hadess@hadess.net>
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
If the kernel is built with platform_profile support,
g_file_get_contents() will fail, and we'll likely crash trying to
access ->message in the struct.
Don't forget to pass the error to g_file_get_contents().
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.
The active profile setting might fail, and we already set it in the
function we call 2 lines below. This avoids the debug function in
activate_target_profile() saying the profile we activate is already the
current one.
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.
When possible, try to restore the previous profile from the kernel
configuration. This makes it easier to force a profile in a startup
script, or pick up in the same configuration if power-profiles-daemon
was restarted for some reason.
Note that this does not save the active profile across reboots (a
systemd unit could be used for that if necessary), and that it will
likely apply the wrong profile if the daemon crashed when an inhibition
or a profile hold were in place.
Closes: #5
