| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
|
|
In up_device_supply_refresh().
|
|
|
|
We cannot ever set the refresh timeout when we have a power line
device, so don't try and remove it there.
|
|
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.
|
|
5 times, with 1 second timeouts, instead of 30 times, with
2 seconds timeouts.
|
|
It was never actually setup, as the fallback state was used
to check whether we should use poll or not.
|
|
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.
|
|
If there are no LED class devices on the system, no need
to print a warning when we cannot open the directory.
|
|
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.
|
|
|
|
As was the case in other places, we need to be able to differentiate
warning messages for them to be useful.
|
|
No way to know which one was being called otherwise
|
|
Replace them all with WarningLevel tests.
Note we current crash when adding a UPS, in test_ups_ac.
|
|
|
|
|
|
In the integration tests.
|
|
As can happen with missing metadata, we might not have a time
to empty, so rely on the percentage instead.
|
|
|
|
Proxy paths, and enumeration from the current API.
|
|
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
|
|
|
|
In up_device_supply_get_state()
|
|
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.
|
|
We're going to be reusing this elsewhere.
|
|
We already have enough information on the device battery.
This avoids having a device for the wacom AC which we won't use.
|
|
Not all "UpDeviceSupply" actually supply power to the computer.
|
|
When the device was removed, we forgot to cancel sending
out changed properties, causing illegal memory accesses.
|
|
|
|
|
|
|
|
|
|
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.
|
|
A simple reversed check...
|
|
So we can update the display device warning level.
|
|
The WarningLevel property just replicated the warning level
on the display device, or at least should have. So we fix the latter
to remove the former.
|
|
|
|
Those are also part of the display device properties that we
will update.
|
|
/org/freedesktop/UPower/devices/DisplayDevice is a stable
object path.
|
|
When it doesn't actually change, don't send out signals.
|
|
The interface name was missing ".Device" at the end, so wasn't
getting registered by clients.
|
|
The IconName and WarningLevel properties were not sent out through
PropertiesChanged when they changed for devices.
|
