This has 2 effects:
- we never stop polling (we used to stop polling when the
battery was marked as fully-charged, but that can happen when
the battery is discharging too)
- when in an unknown state, we will poll through the daemon,
and through our unknown poll. This isn't a problem as there'll
another 115 seconds of wait until we get to poll through the
daemon again.
To be used by all polling backends. This changes the defaults
to poll every 120 seconds when a warning level isn't reached, and
switch automatically to 30 seconds poll when the battery level is low.
For system integrators. If your firmware is helpful to user space
and automatically sends out uevent when the battery level changes
(rather than just the battery state) as on most machines,
you can enable "NoPollBatteries" in the configuration option,
and reduce power consumption from UPower and its listeners.
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.
