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
Many Android devices only export charge_full and capacity, but not charge_now
or energy_now. In that case, directly read the percentage (from the capacity
attribute) and calculate current energy from that.
Thanks to Seth Forshee for the original patch!
https://bugs.freedesktop.org/show_bug.cgi?id=68337
Drop the two modes depending on whether or not the test gets run as root or
not. Set up a fake system bus and always use that. This also eliminates the
need for upowerd's --test option.
Drop usage of dbus-launch, as this leaves dbus-daemon running after the tests.
Use GioTestDBus instead, which cleans up properly.
