For supplies that report the voltage_min_design, voltage_max_design, and
capacity_level attributes on sysfs, expose them via libupower for possible
use 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>
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.
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.
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
Now that we send out PropertiesChanged signals (on the daemon side)
and "notify" signals (on the client side), there's no need for the
all encompassing DeviceChanged and Changed signals.
They would have woken up any client, even if they were not interested
in receiving the signals.
gnome-settings-daemon creates a composite UpDevice that's not
backed by any real D-Bus object in UPower, so we shouldn't
try and poke the inexistant proxy in this case.
We'll cache the properties that the caller sets in this case,
but will not support sending back default/unset values.
The recalls for that broken batch of Sony batteries dates back from
2006. All the batteries that could have been recalled have now
been recalled, and somebody particularly interested in supporting
them can match the batteries using the old rules file, in a
user session or a separate daemon.
When requesting fewer history elements than we actually have, fix the
interpolation loop to not reverse the returned elements; this already does not
happen if we request more elements than available, which led to the returned
list order depending on the history size.
Now the first array element is always the most recent one. Update documentation
accordingly.
Add test case to reproduce the problem. We now add three sample points to be
able to request a subset and still assert its correct order, and make the
charge values be further apart to ensure correct interpolation.
https://bugs.freedesktop.org/show_bug.cgi?id=68384
Linux's power_supply class supports a temperature attribute, which is
supported by many battery drivers. Add a new property to export this
information and support this property in Linux.
https://bugs.freedesktop.org/show_bug.cgi?id=68338
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Martin Pitt <martinpitt@gnome.org>
This adds the luminosity property for devices able to recharge using light.
Signed-off-by: Julien Danjou <julien@danjou.info>
Signed-off-by: Richard Hughes <richard@hughsie.com>
GLib 2.33 and further deprecates GValueArray. However, we still need it as long
as we are using dbus-glib, so selectively disable the deprecation warnings for
the three functions that use GValueArray. This allows us to continue to build
with -Werror.
