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.
* plugins/{flashrom,superio]: Add GUIDs for StarBook Mk VI - Intel
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
* plugins/{flashrom,superio]: Add GUIDs for StarBook Mk VI - AMD
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
* plugins/{flashrom,superio]: Add GUIDs for Byte Mk I - AMD
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Saving the quirks in the GResource section worked well, but it made the build
system very complicated and also meant the .data section was duplicated in
both `fwupd` and `fwupdtool` -- negating a lot of the hard-fought savings.
Simplify this feature so that we just `cat` all the quirk files together, then
gzip them into a single file. This means that at startup fwupd only needs to
check the mtime of one file, and weirdly it's actually faster to load a smaller
compressed file from disk that it is to load multiple uncompressed files.
Add the HwId for the Star LabTop Mk III when using coreboot firmware,
as this differs to AMI.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
This fixes a potential critical warning (seen in the hailuck plugin,
although others may be affected too) where the parent does not set the
ID before the child sets the number of steps.
It's much more helpful to have the child position for debugging anyway,
so just set it in all cases.
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.
This allows creating the silo when starting the engine with custom
plugin keys such as WacomI2cFlashBaseAddr.
If we move the plugin initialization earlier then we don't get the
HwID matches, so we really do have to split this into a 4-stage startup,
e.g. ->load(), ->init(), ->startup() and ->coldplug().
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.
tristate features will automatically disable if dependencies marked
as required are missing.
Packagers can manually override using `auto_features`.
Link: https://mesonbuild.com/Build-options.html#features
We were calling g_module_symbol() 2703 times, which is actually more
expensive than you'd think.
It also means the plugins are actually what we tell people they are:
A set of vfuncs that get run. The reality before that they were dlsym'd
functions that get called at pretty random times.
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.
