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.
We should have inhibited the performance profile when "no_turbo" was set
to "1", but we didn't take the linefeed into account, so we never
actually read that value.
g_udev_device_get_sysfs_attr_as_boolean_uncached in libgudev <= 234 does
not work, see: https://gitlab.gnome.org/GNOME/libgudev/-/issues/7
Since the dytc_lapmode file always contains an integer 0/1 value we
can easily workaround this libgudev issue by switching to
g_udev_device_get_sysfs_attr_as_int_uncached.
Also update the tests to include the '\n' for the dytc_lapmode sysfs
attribute values, like on real hardware.
The platform_profile_choices sysfs file contains the available profiles
separated by spaces, not newlines, with a newline at the end (as all
text based sysfs files have a newline at the end).
Replace the g_strsplit(..., "\n", -1) with a g_strsplit_set (..., " \n", -1)
so that the choices get split on the spaces, and the trailing "\n" gets
discarded.
Also update the integration-test to match.
Change platform_profile_choices before platform_profile, so we only get
probed when all the profile choices are available.
This behaviour is similar to what the kernel drivers do, setting up
the bitmask of choices, before running platform_profile_register().
have_text_in_log() just checks for the presence of that string in the
log for the *whole* test, not just for that text to appear. We should be
checking the number of instances before the change and after the change
if we wanted to do this well, but it's easier to wait a little for a
property change on the D-Bus interface.
thermald can disable turbo altogether if needed to avoid reaching
too high operating temperatures, so make the p-state driver monitor
this, and mark the performance mode as inhibited if "no_turbo" is
set.
Closes: #14
The original idea was to have a "SelectedProfile" property that would be
settable by the user, but could be different from the "ActiveProfile" if
the hardware's performance mode wasn't available for example.
It turns out that having 2 separate states makes for very confusing UI,
so if the performance profile becomes inhibited and it's the current one,
the active profile will automatically switch to balanced and stay there.
That allows API users to programmatically check whether a particular
functionality is implemented in the daemon, eg. if we wanted to move
GPU performance modes from gamemode to this daemon, gamemode could
query whether that feature was implemented and available in the backend.
Closes: #12
