| Top | |
|
|
|
HoldProfile (IN s profile, IN s reason, IN s application_id, OUT u cookie); ReleaseProfile (IN u cookie);
ActiveProfile readwrite s PerformanceInhibited readable s PerformanceDegraded readable s Profiles readable aa{sv} Actions readable as ActiveProfileHolds readable aa{sv}
The power-profiles-daemon API is meant to be used by parts of the OS or desktop environment to switch system power profiles based on user choice, or user intent.
OS components would typically use the "Profiles" property to construct their UI (2 or 3 profiles available), and monitor the "ActiveProfile" and the "PerformanceDegraded" properties to update that UI. The UI would try to set the "ActiveProfile" property if the user selected a different one.
Note that the reason why the project exists and how it is different from existing projects is explained in the project's README file.
The object path will be "/net/hadess/PowerProfiles".
HoldProfile (IN s profile,
IN s reason,
IN s application_id,
OUT u cookie);
This forces the passed profile (either 'power-saver' or 'performance') to be activated until either the caller quits, "ReleaseProfile" is called, or the "ActiveProfile" is changed by the user.
This should be used programmatically by OS components when, eg. high- performance workloads are started with the "performance" profile, or battery will soon be critically low with the "power-saver" profile.
When conflicting profiles are requested to be held, the 'power-saver' profile will be activated in preference to the 'performance' profile.
Those holds will be automatically cancelled if the user manually switches to another profile, and the "ProfileReleased" signal will be emitted.
|
|
|
|
|
|
|
|
ActiveProfile readwrite s
The type of the currently active profile. It might change automatically if a profile is held, using the "HoldProfile" function.
PerformanceInhibited readable s
This property is deprecated, and unused since version 0.9.
PerformanceDegraded readable s
This will be set if the performance power profile is running in degraded mode, with the value being used to identify the reason for that degradation. As new reasons can be added, it is recommended that front-ends show a generic reason if they do not recognise the value. Possible values are: - "lap-detected" (the computer is sitting on the user's lap) - "high-operating-temperature" (the computer is close to overheating) - "" (the empty string, if not performance is not degraded)
Profiles readable aa{sv}
An array of key-pair values representing each profile. The key named "Driver" (s) identifies the power-profiles-daemon backend code used to implement the profile.
The key named "Profile" (s) will be one of: - "power-saver" (battery saving profile) - "balanced" (the default profile) - "performance" (a profile that does not care about noise or battery consumption)
Only one of each type of profile will be listed, with the daemon choosing the more appropriate "driver" for each profile type.
This list is guaranteed to be sorted in the same order that the profiles are listed above.
Actions readable as
An array of strings listing each one of the "actions" implemented in the running daemon. This is used by API users to figure out whether particular functionality is available in a version of the daemon.
ActiveProfileHolds readable aa{sv}
A list of dictionaries representing the current profile holds. The keys in the dict are "ApplicationId", "Profile" and "Reason", and correspond to the "application_id", "profile" and "reason" arguments passed to the HoldProfile() method.