Age | Commit message (Collapse) | Author | Files | Lines |
|
Next up is doing this for batteries, which need to switch between
a normal/slow poll to a faster one when the battery state is unknown.
|
|
|
|
And remove the gathering of the battery poll from the device
itself, it's of nearly no use.
|
|
|
|
Matching the work done in glib, gtk+, etc.
This also differentiates the unknown and normal timeouts in
the Linux power supply driver.
|
|
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.
|
|
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.
|
|
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.
|
|
|
|
As was the case in other places, we need to be able to differentiate
warning messages for them to be useful.
|
|
Replace them all with WarningLevel tests.
Note we current crash when adding a UPS, in test_ups_ac.
|
|
|
|
|
|
In the integration tests.
|
|
Proxy paths, and enumeration from the current API.
|
|
|
|
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.
|
|
|
|
|
|
|
|
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...
|
|
And remove ifdef's.
|
|
Paraphrasing from the configuration option:
The action to take when "TimeAction" or "PercentageAction" above has
been reached for the batteries (UPS or laptop batteries) supplying
the computer.
This is done 20 seconds after the warning-level variable got set
to UP_DEVICE_LEVEL_ACTION has been set, to give the opportunity
to front-ends to display a (short) warning.
This is only implemented for the Linux backend, using logind.
|
|
With "warning-level" property.
|
|
It's already done by GObject.
|
|
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.
|
|
|
|
|
|
This is the case for some devices like the Wacom wireless (Bluetooth)
tablets, and shouldn't produce a warning.
|
|
Don't wait for tty events from udev if we're not going to
use the Watts Up device anyway. Cuts down on the possible wakeups.
|
|
If the device state is unknown, don't guess based on the laptop's
power supplies (battery/power line) as it might not be charging
from there.
https://bugs.freedesktop.org/show_bug.cgi?id=70321#c1
|
|
|
|
Drop a lot of unused variables
|
|
Start testing the client-side library through gobject-introspection.
This covers https://bugs.freedesktop.org/show_bug.cgi?id=70283
|
|
The full native sysfs path of wireless HID battery devices contains a lot of
jitter like USB tree layout or sequence numbers which change after every resume
from auto-suspend. Plus, there are kernel bugs which don't give proper remove
events for those: http://bugzilla.kernel.org/show_bug.cgi?id=62041
As device names within the same subsystem must be unique anyway, and we only
use the device name for constructing the D-BUS object path, only consider the
device name for the device list native → upower object lookup table, i. e. in
up_native_get_native_path().
This fixes the "A handler is already registered for <battery>" assertion crash
if a bluetooth device comes back from auto-suspend. This fixes the
test_bluetooth_mouse_reconnect() test case, drop the expected failure.
https://launchpad.net/bugs/1112907
|
|
When these power down, we don't get remove uevents for the original
power_supply devices from the kernel, but instead we get new devices with a
different sequence number, but the same name:
UDEV [6408.025124] add /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/bluetooth/hci0/hci0:12/0005:0D62:0558.0001/power_supply/hid-00:0f:f6:6d:8e:c0-battery (power_supply)
UDEV [23785.90673] add /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/bluetooth/hci0/hci0:12/0005:0D62:0558.0002/power_supply/hid-00:0f:f6:6d:8e:c0-battery (power_supply)
This circumvents the existing "treating add as change" check (as the native
path is different) but breaks later on when building and registering the
(supposedly) new object:
ERROR **: Failed to register GObject with DBusConnection: org.freedesktop.DBus.Error.ObjectPathInUse A handler is already registered for /org/freedesktop/UPower/devices/mouse_hid_000ff66d8ec0_battery
This reproduces https://launchpad.net/bugs/1112907
|
|
Don't just cover the test upowerd by umockdev-wrapper, but the test suite
itself as well, so that we can send uevents.
Do this by re-execing the test suite under umockdev-wrapper if it's not already
running under it.
|