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
Those levels will not be used to cover warning levels, but approximate
battery levels that devices can use, exported by the kernel as
POWER_SUPPLY_CAPACITY_LEVEL_* values.
See linux/power_supply.h
https://bugs.freedesktop.org/show_bug.cgi?id=100359
GObject _new constructors should always return a new pointer and not do
anything else than g_{object,initable}_new(). Drop the internal
up_client_object singleton instance.
This simplifies the code and makes the code robust with multiple threads.
Side issue in https://bugs.freedesktop.org/show_bug.cgi?id=95350
A GObject's _init() should never fail or block, but this is currently the case
as up_client_init() connects to upowerd on D-Bus. Convert this to the GInitable
interface and provide a new constructor up_client_new_full() which accepts a
GCancellable and GError, so that clients can do proper error handling
and reporting.
This changes up_client_new() to return NULL when connecting to upowerd fails.
This provides a more well-defined behaviour in this case as clients can check
for this and our methods stop segfaulting as they have checks like
g_return_val_if_fail (UP_IS_CLIENT (client), ...)
Previously we returned a valid object, but trying to call any method on it
segfaulted due to the NULL D-Bus proxy, so client code had no chance to check
whether the UpClient object was really valid.
https://bugs.freedesktop.org/show_bug.cgi?id=95350
This allows using e.g. g_autoptr(UpDevice) in other programs, but does
not make upower itself use g_autoptr, or require a new enough glib to
support it.
Signed-off-by: Richard Hughes <richard@hughsie.com>
