This will allow DE environments to decide whether they want to allow
actions and profiles to dynamically change from the battery level or
AC adapter presence.
The too-many-positional-arguments warning introduced in commit 4a367430
caused a regression in pylint-integration-tests for versions of pylint < 3.3.0,
as these versions do not support the too-many-positional-arguments check.
Added disable=unknown-option-value to the pylint disable line for compatibility
with pylint < 3.3.0, avoiding test failures.
Kept disable=too-many-positional-arguments for pylint >= 3.3.0, since the
function exceeds the maximum allowed positional arguments (R0917) and may cause
lint errors.
Fixes: https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/issues/174
Rather than checking for active mode at startup and then never checking
it again check the mode when trying to write a value.
If it's not active, log something to the journal. This is intentionally
not failing because users could still have an ACPI platform-profile change
occur.
Fixes: https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/issues/168
PPD doesn't force the SoC to active mode or to load.
As the policy of whether amd-pstate is loaded is controlled by the
kernel having another policy whether power-profiles-daemon isn't
necessary.
More users use power saver as their default value than expected, and
so ABM is a more negative experience for some of them.
Instead of a table of values, use "progressive" values that change
based on battery life.
The selected values:
* Balanced + AC:
ABM 0
* Balanced + battery:
>= 30% battery
ABM 0
< 30% battery
ABM 1
* Power Saver + AC:
ABM 0
* Power Saver + battery:
>= 50% battery
ABM 0
30-49% battery
ABM 1
20-30% battery
ABM 2
<20% battery
ABM 3
Although the system will save more power at lower frequency, AMD SoCs
have a point when they can operate most efficiently called the lowest
non-linear frequency.
Program the minimum frequency to this value in balanced and performance
modes to improve responsiveness.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Simplify our writing function by just using pure C open/write calls
since we don't really need to be able to create files.
In fact this made possible to spot a test issue where a file was not
present and in fact in some scenarios we had random valgrind errors in
CI.
Plus, since we just need to write the contents as it is, we can avoid
extra buffers.
We might have notified the drivers even for no actual changes, so
let's refactor the code so that we only notify them when we really have
a battery state change.
assert_eventually() can check if a condition eventually is true, but
this could change after a while. So add another function that allows
to check if a condition persists for a given time.
This is a regression of commit 18a9c6668, due to the fact that the
argparse func return value is simply ignored.
So let's just exit directly with the provided return value in such case.
When the system is on AC and profile is balanced put the EPP value
of balanced_performance.
When the system is on battery and profile is balanced put the EPP value
of balanced_power.
