The startup polling just creates the idevice_t. It is trivial to detect
that, so move it into the refresh handler and set the initial polling to
the shorter period, increasing the poll interval later on.
There are two users, and both simply force a device refresh. We also
simply force-refresh devices after resume, which ties into
pausing/resuming polling.
The reason of a refresh may be interesting to special case certain
situation (e.g. discontinuity of charge after wakeup, polling again
after an event). As such, add an enum parameter that signals the reason
for the refresh.
There are only a few cases where we separate construction and coldplug.
Porting to GInitable is relatively natural here and makes the code a
little nicer overall. In the case that immediate coldplug/initialization
is not desired, we can still split the operations.
Rather than this weird situation where they are immediately passed in
through the "coldplug" method. Doing this is the first step to make
UpDevice into an initable object (removing the "coldplug" method).
The refresh functions only ever returned whether data was successfully
fetched or not. The failure return code was unused and the corresponding
code can be removed.
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.
The open() call needs to check against the FD being <0 for error
detection. Also, add a missing close in one of the error paths and
change the code to let the input stream close the FD when it is not
needed anymore.
We still open() it manually just because we need to do an ioctl once.
At least for "change" events the device is most likely simply one that
we are not handling at all. For these, we will convert the event to
"add" and continue to ignore it later on.
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.
Prevents a spurious warning:
"did not recognise USB path /sys/devices/platform/USBC000:00/power_supply/ucsi-source-psy-USBC000:001, please report"
This does not actually change any functionality, as the heuristic for
the attribute "online" in up_device_supply_coldplug() would have
matches id, too.
Fixes#148
77 is the special value meaning that the test was skipped. Both meson
make check will display the information correctly.
Note that the test is currently executed directly in check-local. So add
a workaround to ignore the 77 error code and exit 0 instead in that
case.
Inhibitor lock should be taken between the critical
action notification and the execution of the critical action.
Requires python-dbusmock > 0.23.1, test is skipped on lower versions.
python-dbusmock in the CI is installed from git and bumped version
to 0.23.2 until a new release is available.
Phones are suspended most of the time so they are not awake for > 20s
to allow UPower to take action when battery is critical.
Add an interface to take and release inhibitor locks which
prevent the device from suspending to allow UPower to execute
the critical power action.
USB PD 3.1 allows up to 240W (48V, 5A) and some proprietary supplies
already delivered more than 100W over USB-C (USB PD 3.0 limit).
Closes: #147
Reported by StefanBruens
