Since d2053eff ("linux: Remove user-space support for Logitech Unifying
devices"), the luminosity property is no longer in use and no code for it
exists except in the lib. Deprecate and eventually drop it.
The object path /org/freedesktop/UPower/KbdBacklight is going to be deprecated in the future.
The upper-layer app should migrate to the new API instead.
The types of settings for charge thresholds that are supported. The value
is a bitmask value and it is the sum of the supported types.
1: The system supports charge start threshold. The battery discharges to a
percentage, then starts charging.
2: The system supports charge end threshold. The battery charges to a
percentage, then stops charging.
4: The system supports optimized charging behaviors controlled by the
system firmware.
Examples:
If the system supports charge start threshold and charge end threshold,
the value is 3.
If the system supports charge end threshold and the battery charging
behavior is controlled by the system firmware, the value is 6.
Some drivers provide capacity_level, voltage_min_design, and voltage_max_design
properties on sysfs even for system supplies. Expose these properties over DBus
for consumption by clients.
Related: #301
Signed-off-by: Sicelo A. Mhlongo <absicsz@gmail.com>
ChargeThresholdSupported property is used to show if the battery supports
Charging threshold feature. ChargeThresholdEnabled is used to show the
configuration (enabled/disabled) status of the feature.
Signed-off-by: Kate Hsuan <hpa@redhat.com>
This reverts commit 07565ef6a1.
In the current systemd stable release 255 org.freedesktop.login1 does
not emit a LidisClosed event, this has added in systemd `main` and will
be availble in the next release.
As GNOME control panel still uses UPower's `LidIsclosed` property and
many other DE's such as Xfce/LXQt/Deepin as well revert this until the
systemd changes are available in all Distributions.
https://github.com/systemd/systemd/pull/30706
Resolve: https://gitlab.freedesktop.org/upower/upower/-/issues/260
The Refresh D-Bus method could be used by clients to force re-reading
the state of batteries in the upower backends. This is not needed as
all the backends should be sending events when their states changes,
removing the need for an explicit refresh.
This is also a potential security problem if applications keep on
refreshing their data.
We now only allow access to the Refresh() method if the daemon was
started in debugging mode. This should make it clearer that it is a
debug tool.
Also remove a mention of the never implemented refresh-power-source
polkit authorisation.
The API relied on /proc/timer_stats which has been removed from the
kernel in 2017. Since then, the API has been non-functional (yet
incorrectly reporting support because the support test was buggy).
Just remove it completely. The debian codesearch does not uncover any
API users. Also, I doubt that any new API (based on tracing scheduler
events as perf would do) would map well to what exists now. i.e. if
something like this is re-implemented in UPower or elsewhere, then the
API should likely look different.
And, realistically, if this does need root privileges (i.e. can't be
moved to use BPF programs or so on user units), then we can also create
a new small daemon that is launched on-demand just for that.
Export approximate battery levels that devices can use, exported by
the kernel as POWER_SUPPLY_CAPACITY_LEVEL_* values.
This avoids bizarrely accurate values showing up in UIs when we only
have ok/warning levels of accuracy in some cases.
https://bugs.freedesktop.org/show_bug.cgi?id=100359
There are multiple possible causes for the keyboard brightness to change,
e.g. SetBrightness may get called, or the brightness may get changed
through a hotkey which is handled in firmware.
https://bugs.freedesktop.org/show_bug.cgi?id=98404
