Some clients (notably GNOME) look specifically for both the path and
interface. To avoid breaking them on profile change events make sure
to emit signals on both the legacy and modern interface.
Some systems have multiple GPUs with an eDP output but the panel
isn't connected to all of them (or it's controlled by a mux).
Handle this case by ensuring that the panel is connected when
before writing an attribute.
Expose the daemon as 'org.freedesktop.UPower.PowerProfiles' by default
but we also own the old 'net.hadess.PowerProfiles' name for
compatibility resons.
Also dbus objects are now registered also in the path
/org/freedesktop/UPower/PowerProfiles and they implement the
org.freedesktop.UPower.PowerProfiles interface.
Even in this case we preserve the compatibility with the old ones.
To make this switch as most reliable as possible, the code is now
generated for dbus configuration files preserving the previous ones as
base.
Tests are now performed checking both names, to ensure again that we're
not breaking the expectations for the old APIs consumers.
It's still quite old, but provides some features we may want to use in
future, so let's use a newer version since we're about to release a new
major version of p-p-d too.
Some distros as LTS ones may still have old versions of polkit
gobject.
Since we only depend on the new polkit because of auto-pointers,
let's add a tiny compatibility layer to make possible to get
p-p-d also working on older stable distros as OEMs may like.
Remove a lot of the unnecessary stuff about the process, and instead
pad out the domain to make it more accessible.
If running on an interactive terminal add color coding for warnings
and errors. If this behavior is not desirable for an interactive terminal,
NO_COLOR=0 can be set in the environment.
Running Tests.test_fake_driver breaks stdin on a real terminal unless
the test suite is run as root. It doesn't make sense for the fake
driver to capture stdin unless we are sure that we're interactive.
Lookup whether stdout is a tty and only run the keyboard setup in
probe for the fake driver if we're sure we're interactive.
Using powerprofilesctl to launch an app would always result in what was
detected as success, because the code wasn't propagating the retval from
the launched application.
This mirrors the behavior used by Kernel 6.5 and later where amd-pstate
is configured to default into 'performance' by the kernel. It's not
as useful in server to be changing it.
Link: 32f80b9adf
Drivers can be blocked from loading via `POWER_PROFILE_DAEMON_DRIVER_BLOCK`
which is a comma separated value listing the drivers to block.
This is an escape hatch in case CPU or platform driver are failing and a user
would like to block them.
Make it easier to see which features are used on the system by
summarising the features the driver will use.
** (power-profiles-daemon:126721): DEBUG: Found Intel p-state settings
** (power-profiles-daemon:126721): DEBUG: Energy Performance Preference: yes
** (power-profiles-daemon:126721): DEBUG: Energy Performance Bias: yes
** (power-profiles-daemon:126721): DEBUG: Has Turbo: yes
Closes: #120
The AMD P-states driver has added support for active mode in kernel 6.3,
which exposes a similar interface for controlling energy performance
preference as the Intel P-state driver, with the same presets present,
so make use of it.
See:
https://www.kernel.org/doc/html/v6.3/admin-guide/pm/amd-pstate.htmlCloses: #108
src/powerprofilesctl:137:0: C0325: Unnecessary parens after '=' keyword (superfluous-parens)
src/powerprofilesctl:126:4: R1720: Unnecessary "else" after "raise", remove the "else" and de-indent the code inside it (no-else-raise)
src/powerprofilesctl:134:4: R1720: Unnecessary "else" after "raise", remove the "else" and de-indent the code inside it (no-else-raise)
src/powerprofilesctl:154:4: R1720: Unnecessary "else" after "raise", remove the "else" and de-indent the code inside it (no-else-raise)
The "cool" profile isn't a low-power mode, but a mode where the fans are
always running to reduce the temperature, presumably to allow it to run
faster.
At the same time, we need to handle the lack of low-power profile on HP
machines as they only had a cool mode and no low-power mode.
Closes: #89
