When polling is resumed the timeout needs to be reevaluated. This
requires running the polling handler once (in the next mainloop
iteration).
Set the ready time to zero to ensure this is happening. Without this, we
would be stuck without actually polling until we get a uevent from the
kernel on one of the power supplies.
Fixes: #198
When a battery is swapped the old history needs to be saved and the
other history should be loaded.
Change the code to load the history lazily when needed. Then, to reload,
we purely need to clear the history object and it'll be loaded again
when required.
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 should be quite robust, in particular as we should be getting
notifications about AC plug/unplug.
The value for the battery will lag a few seconds. However, the
DisplayDevice will do some guessing taking the AC state into account,
and as such the user should get at least some immediate feedback.
Closes: #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).
We keep giving people these commands for bug triaging. So, lets hope
that adding them to the README removes some of the overhead and can be
helpful to users.
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.
There is no reason to not guess the state if the device has no AC power
and there is more than one battery. Remove the corresponding constraint.
Related: #146
Otherwise we may not have the percentage to work with, rendering the
guessing useless. This also moves the time estimation down (after the
state guessing) and does it unconditionally. This is, however, not an
issue, as the calculation matches with other places.
Related: #146
Using energy is broken as the value might be zero if it is not provided.
However, either energy or percentage ("capacity") should have been read
from the sysfs. And, in both cases the percentage should reflect
something reasonable.
Related: #146
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
If we have an input node with both a keyboard and a mouse in one node,
then prefer the mouse. However, if we have separate mouse and keyboard
device nodes, prefer the keyboard.
Closes: #189
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.
Stop trying to guess a battery state based on the AC information for a
single battery. Instead, just do the guessing in the display device.
This means that cases with more than one battery work fine. It also
means that we still report an UNKNOWN state for the battery itself.
Also get the on_battery information from the display devices discharging
state, there is no need to iterate all of the batteries to figure that
out.
Note that we don't really have a well defined state for the display
device in all cases. We'll add a test in the next step, marking those
cases as TBD or ANY to show where the issues are. AFAICT we do not have
a regression though, so this should be fine for now.
Fixes: #146
This fixes the previous commmit to 190d12e292 ("common: Add a file
with common helper") which broke the string handling for the freebsd
backend.
Related: !144
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.
This removes some code duplication between the linux and freebsd
backend. And, this file could become home to other small helper
functions in the future.
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.
It appears that the parent ID lookup may not properly work when devices
are removed. Likely, because corresponding sysfs entries may not exist
anymore.
Fix this by attaching the ID to the stored object, allowing us to remove
it without calling device_parent_id() again.
Fixes: #185
