The local variable 'bus' was shadowing the global 'bus' variable;
to not confuse the two, rename the local one. Also unref the local
bus, i.e. fix a small memory leak.
MAX_GOVERNOR_LENGTH is defined as PATH_MAX + 1, so when comparing
two variable, each of once size, use the smaller one, i.e. PATH_MAX.
Assert statically that MAX_GOVERNOR_LENGTH is larger then PATH_MAX
so copying a string to a MAX_GOVERNOR_LENGTH sized variable from a
PATH_MAX size variable will not truncate the string.
If there is no null byte among the first n bytes of the source the
resulting string will not be properly null terminated.
Ensure that all strings that are copied via strncpy are properly
terminated copy "sizeof (dest) - 1" bytes and manually terminate
the string in the cases the array was not initialized.
Example compiler warning:
../daemon/gamemode-tests.c: In function ‘run_cpu_governor_tests’:
../daemon/gamemode-tests.c:326:4: warning: ‘strncpy’ specified bound
256 equals destination size [-Wstringop-truncation]
strncpy(defaultgov, currentgov, CONFIG_VALUE_MAX);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SCHED_ISO is not supported by upstream kernels, so don't try to use this by
default since for most users it will result in an error log that trying to
set the scheduling policy fails.
Without extra system configuration, we will also not have permission to renice
processes by default, so out of the box doing this will fail as well.
Users that wish to use these features can enable them from the config once
they have configured their system appropriately.
This should hopefully fix issue #113, where the user was in the common situation of having an intel and an nvidia GPU, at card0 and card1 respectively, but the nvidia gpu was [gpu:0] according to the driver
The drm device ID doesn't match up with the pci device as expected, spotted by issue #113
I can't test this myself just yet, will need data from the user in question to verify PCIDevice is the right value
This also fixes the instances in testing where we don't have the nv overclock in use, but we do have the mode set
Solves issues explaining the what the perf_level actually meant, and future proofs for any PR that wants to set individual perf levels
This covers the MVP for now, and simply allows pinning the power level to "high"
Full overclocking set up is somewhat more complicated, and it'll be better to implement that at the same time as the same for Nvidia, where we're currently only really setting the top end power level
This allows direct control over who can make requests on behalf of other processes
require_supervisor can also be used to allow a supervisor to take direct control of gamemode on the system (perhaps a GUI, or game launcher)
