This allows us to ignore all the delays when the device is emulated, with the
idea being to do dozens of device emulations in the CI tests.
Also, do not call fu_progress_sleep() when the device is emulated.
This allows us to print better warning strings, and in the future
would allow us to profile each operation in a meaningful way.
Also, add context to some of the progress steps as required.
Provide a device instance builder that allows plugins to easily
create multiple instance IDs based on parent attributes.
Also fix a lot of the instance ID orders, so that we add more generic
IDs first, and more specific IDs after.
At the moment a lot of the failures are only visible when running the
daemon in verbose mode, and the inhibit functionalit provides us a way
to unset FWUPD_DEVICE_FLAG_UPDATABLE from multiple places, as well as
setting the update error for the user to see why.
It's actually quite hard to build a front-end for fwupd at the moment
as you're never sure when the progress bar is going to zip back to 0%
and start all over again. Some plugins go 0..100% for write, others
go 0..100% for erase, then again for write, then *again* for verify.
By creating a helper object we can easily split up the progress of the
specific task, e.g. write_firmware().
We can encode at the plugin level "the erase takes 50% of the time, the
write takes 40% and the read takes 10%". This means we can have a
progressbar which goes up just once at a consistent speed.
The RTD2141B has the same update protocol as RTD2142, but the Chromebook
targets that use it require us to find the drm_dp_aux_dev i2c channel
differently because the AMD display driver doesn't give each output a
unique name in sysfs, so it must be found by walking sysfs from the drm
device representing an output.
Change-Id: Icb6c1a40b8a62af72808d68a0a69555810abc272
