And make device-removed send an object path, not a UpDevice.
This means that we don't keep all the remote devices as local
UpDevices object, getting woken up any time any of them have a
property changed, without anybody listening.
This should greatly cut down on the wakeups on the client side,
especially for applications that only use a small portion of the API
like the "on-battery" or "warning-level" properties.
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.
This allows desktop front-ends to get which action will
actually be taken when we hit critical battery.
This is not a property as availability of actions might
change over the course of the run of the system, and
we didn't want to make unnecessary D-Bus calls on startup.
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.
It was added for some workloads, but ill-suited and never really
got traction. Using cgroups to manage the resources of particular
services (using systemd), or something separate like rtkit is
a better bet.
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.
db89e5a32b was incomplete and
"ret" was being used instead of prop_val to set some of those
properties. It's likely your laptop would have been seen as
docked for example.
In up_client_get_properties_sync(), don't set the passed GError** to NULL,
instead set the actual pointed-to GError* to NULL by default.
Fixes proper error reporting back to the client if something does fail.
We would error out when trying to get properties that are
disabled by default (deprecated). Ignore those properties
when building without the deprecations.
This is still broken if the library is built with the deprecations
enabled, but not the daemon isn't, but that's an edge case.
https://bugs.freedesktop.org/show_bug.cgi?id=70283
Signed-off-by: Martin Pitt <martinpitt@gnome.org>
If one of the properties is FALSE, we'll end up return FALSE
without setting an error (and making the caller crash if they
expect an error being filled in).
https://bugs.freedesktop.org/show_bug.cgi?id=70283
Signed-off-by: Martin Pitt <martinpitt@gnome.org>
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 can easily be done by doing #define UPOWER_ENABLE_DEPRECATED before
"#include <upower.h>" or adding -DUPOWER_ENABLE_DEPRECATED to the cflags line in
Makefile.am
See http://lists.freedesktop.org/archives/devkit-devel/2013-January/001339.html
for more information on future plans and for rationale.
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.
