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.
The usb3 hub 413c:b06f may be added to the plugin ahead of ec device
while dock type is yet known at that time. Cache the hub until ec can
tell the instance id, then add it to the plugin.
This allows us to make smarter policy decisions in the future on when
to show unavailable updates. It also means we can show translated
text in the frond-end clients.
Only problems the user can "fix" are enumerated. For example, opening
the laptop lid, or charging the device battery.
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().
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.
This commit resolves a warning message at runtime:
- no GUIDs for device ...
fu_device_add_child emits a child-added signal afterwards the engine
try to add given device and verify whether GUIDs is set.
* dell-dock: open usb4 device in the activate call, and leave early
* trivial: read history earlier, at least before plugin register
* dell-dock: activate usb4 device exclusively if it needs activation
The CustomFlags feature is a bit of a hack where we just join the flags
and store in the device metadata section as a string. This makes it
inefficient to check if just one flag exists as we have to split the
string to a temporary array each time.
Rather than adding to the hack by splitting, appending (if not exists)
then joining again, store the flags in the plugin privdata directly.
This allows us to support negating custom properties (e.g. ~hint) and
also allows quirks to append custom values without duplicating them on
each GUID match, e.g.
[USB\VID_17EF&PID_307F]
Plugin = customflag1
[USB\VID_17EF&PID_307F&HUB_0002]
Flags = customflag2
...would result in customflag1,customflag2 which is the same as you'd
get from an enumerated device flag doing the same thing.
