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.
We did terminate the daemon and waited for it, but we did not ensure
that it was terminated with no error.
This is particularly a problem when we are running the sanitizers or
valgrind, because we didn't catch any error.
Thus... We were living with some leaks that we never caught :)
This implies a SIGTERM, and so will trigger the daemon clean teardown,
making it exit correctly.
In this way the coverage data is correctly generated, making finally our
coverage reports to be real!
Fixes: #137
It can be useful to inspect the daemon logs in any case, so let's show
the logs details when running in meson.
Then it's up to use the `--verbose` parameter to decide whether to see
them or to inspect them from the generated logs.
Daemon may take some moments to do IO operations, and the tests
may be too fast in reading this.
As per previous cleanups this become a problem when testing in
slower scenarios (as valgrind), so take the opportunity to
cleanup the tests so that we always wait for file contents to
match the expected one.
