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
This reverts commit 6766602954.
Removing this and renaming up_client_get_devices2 to
up_client_get_devices means consumers have to support three cases to
support older UPower versions. So for example GNOME Control center now
uses up_client_get_devices2 and would have to now check if UPower
version > 0.92.
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.
The daemon sources and libupower-glib were built without their historic
log domains which meant some debug messages did not appear when running
upowerd in verbose mode.
This fixes the test_no_poll_batteries test.
This will be useful to show information about Bluetooth devices which
don't fit in with the existing types, and for which we don't want to
show an unknown kind.
This adds a variety of missing device kinds specific to the Bluetooth
classes supported in gnome-bluetooth [1].
In up_device_to_text these types have only been added to the
`percentage` class, which is currently the only property exposed by
org.bluez.Battery1, where these devices are coming from.
[1]: cf4a0ba59d/lib/bluetooth-utils.c (L165)
Almost every device kind except line power and invalid (>= last) carry a
valid percentage property. By inverting this conditional not every new
device needs to be added explicitly to this already long and lacking
chain (PDA and MONITOR were already missing).
G_TYPE_INSTANCE_GET_PRIVATE has been deprecated since glib version
2.58 and should be replaced with the xxx_get_instance_private (obj)
which is generated by G_ADD_PRIVATE.
Use G_DEFINE_TYPE_WITH_CODE (..., G_PRIVATE_ADD (...)) instead of
the (deprecated since glib 2.58) function g_type_class_add_private
to add a private structure for a type.
Bump the minimal required version of glib to 2.38.0, the version
where G_PRIVATE_ADD was added.
The generated headers for the dbus service are in the build dir, not
the source dir.
../../libupower-glib/up-client.c:39:10: fatal error: up-daemon-generated.h: No such file or directory
#include "up-daemon-generated.h"
^~~~~~~~~~~~~~~~~~~~~~~
The existing function didn't set the free function on the GPtrArray.
This means a libupower user can easily make a mistake in the reference
counting of the array contents.
When UPower would appear, or disappear, we'd get warnings like:
g_object_notify: object class 'UpDevice' has no property named 'g-name-owner'
or:
g_object_notify: object class 'UpClient' has no property named 'g-name-owner'
This was caused by the property proxying added in 7531dbd and 28438a7
being too lax about which properties it tried to proxy, which included
ones that didn't apply to the object types in question.
See https://bugs.freedesktop.org/show_bug.cgi?id=43001https://bugs.freedesktop.org/show_bug.cgi?id=102350
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
