Commit 1550d50f ("linux: Remove "usb" subsystem match") broke detection of
some idevices, since it left just the "usbmisc" subsystem match while some
idevice / kernel combinations (at least an iPhone 11 on a 6.0 kernel) don't
present any such udev usbmisc devices.
However, they do present "usb" subsystem ones, so add this match back.
Leave idevice detection also for the "usbmisc" match since that's what the
original (known working) code before aforementioned commit did - it is
possible that it is required for some kernel / idevice combinations.
It seems that the test was still flaky, the reason for that would be
that we did not explicitly wait for the log line saying that the
aggregate state was calculated.
The only reason that it did not consistently fail appears to be that
searching for the state conflict caused messages to be skipped. That is
wrong, we should account for every "Calculating percentage" message to
ensure that upowerd and the test is in sync.
Assuming we have some estimation for the current battery capacity (i.e.
percentage), we can infer a FULL/EMPTY state. Do so if the battery state
is unknown.
Related: #196
This makes the switch. There are a few behaviour changes with regard to
estimations (which hopefully got both simpler and more robust at the
same time).
The state guessing code based on the AC state was not tested well.
Improve the test by testing both 1 and 2 batteries and checking the
reported state in more detail.
The state aggregation test requires an idle handler to run, which can be
a bit unreliable as it may or may not run twice.
Force running it twice and add code to wait for it to complete. Do so
properly by waiting for the correct log messages rather than sleeping so
that everything is ordered nicely while not slowing down the test a lot.
Closes: #193
This adds a test that checks all possible inputs for the battery state
aggregation. Not all states are actually tested in this case, as some
states may be handled through state inference and others might not be
well defined.
The umockdev code to disable it by setting the variable does not
propagate through python. Set the variable here until there is a more
permament solution available.
Using tearDown is brittle, as an assertion will stop it from running
through completely. So move cleanup into a helper that is called via
addCleanup for logind and bluez.
It can be a bit unepxected if results are not printed immediately, so
turn off buffering. We could possibly also reopen sys.stdout, but this
is good enough in many cases.
Instead of just killing upower, try to send SIGTERM for a clean
shut-down. Kill the process if it doesn't quit within two seconds, and
check that the service exits cleanly.
While not needed currently, there is a discussion to ignore the "hid"
subsystem parents when searching for siblings. Add in appropriate
parents to the tests so that such a change will not result in a failure.
This causes an add that we ignore, after that we should still see
updates from the device (and the add itself should trigger an update).
Verify that this works by setting the capacity to 20.
The hiddev driver has been in the "usbmisc" subsystem since kernel 3.7.0
or so. As such, we can simply drop the "usb" subsystem from our matches
at this point.
Otherwise we flush out the data much more often than needed. With this
change, we'll also wait up to 5 seconds even on lower power. Loosing 5s
of data shouldn't be too bad, and it may prevent additional disk writes.
But, more importantly, we need to deferre writing the data to a later
main loop iteration. If we did not do this, then we have an
write-amplification scenario where the history is written at least 4
times instead of once.
Closes: #150
The changes from 37b6d4b039 ("linux: Fix Bluetooth tests for
python-dbusmock changes") require a not-yet-released dbusmock version.
Simply catch the error and fall back to adding the properties in order
to be compatible with both old and new dbusmock versions of the bluez
service.
