When the AC state changes, let the backends poll for battery changes.
They know better what's _really_ happening (whether the real state
is unknown even if they present a fully-charged battery), etc.
This is only possible because we fixed the Linux backend to poll
as it should always have.
Some batteries report energy > energy_full and a percentage ("capacity"
attribute) > 100%. Clamp these within 0 and 100% for both plausibility as well
as to avoid setting an out-of-range property which would then become 0%.
https://launchpad.net/bugs/1240673
I don't think the kernel exports any numbers with a decimal
portion, but if they did, they would get the wrong values because
some locales use "," as the decimal separator, and not "." as the
kernel/C locale would.
If one battery is draining and the other one isn't, the time
to empty wouldn't be zero, but it would only match the time
to empty for the single battery.
Instead, ignore the accumulated time to empty/time to full
for multiple batteries and recalculate it.
https://bugzilla.gnome.org/show_bug.cgi?id=710344
When UPower crashes, we would never notice the battery going flat
because UPower clients aren't polling UPower, so won't autostart it.
Instead we rely on systemd to restart us when we crash. libupower-glib
also supports the client coming and going.
https://bugzilla.gnome.org/show_bug.cgi?id=682912
Update the expected warning levels to match, and add a big
fat FIXME for the test case itself. That's not how UPSes work,
or how UPower is expected to work.
Failure to refresh was supposed to be non-fatal, but since
we started putting objects on the bus *after* refresh, we
were skipping the registration if refresh failed, as is
the case in the UPS test case.
The Makefile rule was using GI_REPOSITORY_PATH instead of
GI_TYPELIB_PATH meaning that if a custom typelib path was needed
(jhbuild for example) it wouldn't be found.
When switching off Bluetooth devices, and before they timeout,
we won't be able to read the battery percentage, so don't
overwrite the previous value with "0%", but set the state to
unknown instead.
https://bugs.freedesktop.org/show_bug.cgi?id=70325
When refreshing the state of device batteries, no need
to get data that won't be there anyway, such as voltage, temperature,
or consumption rate.
This avoids warnings about voltage being unknown for devices, and
cuts down on the properties churn.
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 is a hack that was in gnome-settings-daemon's power plugin.
We would check whether we were on AC before saying for certain
that batteries had a low-level, and raising the warning-level.
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.
