Export approximate battery levels that devices can use, exported by
the kernel as POWER_SUPPLY_CAPACITY_LEVEL_* values.
This avoids bizarrely accurate values showing up in UIs when we only
have ok/warning levels of accuracy in some cases.
https://bugs.freedesktop.org/show_bug.cgi?id=100359
Those levels will not be used to cover warning levels, but approximate
battery levels that devices can use, exported by the kernel as
POWER_SUPPLY_CAPACITY_LEVEL_* values.
See linux/power_supply.h
https://bugs.freedesktop.org/show_bug.cgi?id=100359
Some devices, such as a number of wireless Logitech unifying devices
don't have a precise battery level reporting, and use the Linux
POWER_SUPPLY_CAPACITY_LEVEL_* values.
This minimal fix matches the levels against approximate percentage
values. This is good enough to make the Logitech T650 report battery
again when using the kernel HID++ battery support.
https://bugs.freedesktop.org/show_bug.cgi?id=100359
Paths supplied to testbed.add_device() are relative to /sys/devices
already and therefore must not start with /sys/devices.
This does not change the result of the test.
https://bugs.freedesktop.org/show_bug.cgi?id=100539
The NoPollbatteries option should disable battery polling. Create
a config file with 'NoPollBatteries=true' and ensure we don't get
polling setup for the virtual battery.
https://bugs.freedesktop.org/show_bug.cgi?id=99763
This is better design to catching regressions and problems in a more
pin-pointed fashion. This also avoids having to restart the umockdev testbed
due to changing the environment variables with stop/start_daemon().
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
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.
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.
These should be detected with their proper type (5/6, not 2) and not count as
powering the system, i. e. their PowerSupply property should be False.
This reproduces https://launchpad.net/bugs/1153488
