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.
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
This allows us to replace the 'dfu-tool replace' with a much more
controlled 'fwupdtool firmware-patch' command that patches at a set of
specific offsets.
Drop in the new functionality into the existing firmware ->write()
vfuncs so that the image headers, footers and/or checksums are correct.
It's a common action for plugins to call FuUsbDevice->open() then claim
interfaces, and then release them just before FuUsbDevice->close().
It's also something a lot of plugins get wrong, so provide common code
to handle it correctly in one place.
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.
Before this change calling FuUsbDevice->open() opened the device, and
also unconditionally added various GUIDs and InstanceIDs which we
normally do in setup.
Then fu_device_setup() would call the FuSubclass->setup() vfunc which
would have no way of either opting out of the FuUsbDevice->setup()-like
behaviour, or controlling if the parent class ->setup is run before or
after the subclass setup.
Split up FuUsbDevice->open() into clear ->open() and ->setup() phases
and add the parent class calls where appropriate.
This means that ->setup() now behaves the same as all the other vfuncs.
Otherwise the following build error happens:
../fwupd-1.6.0/plugins/analogix/fu-analogix-device.c:54:10: error: ‘G_USB_DEVICE_DIRECTION_HOST_TO_DEVICE’ undeclared (first use in this function)
54 | G_USB_DEVICE_DIRECTION_HOST_TO_DEVICE,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../fwupd-1.6.0/plugins/analogix/fu-analogix-device.c:54:10: note: each undeclared identifier is reported only once for each function it appears in
../fwupd-1.6.0/plugins/analogix/fu-analogix-device.c:55:10: error: ‘G_USB_DEVICE_REQUEST_TYPE_VENDOR’ undeclared (first use in this function)
55 | G_USB_DEVICE_REQUEST_TYPE_VENDOR,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../fwupd-1.6.0/plugins/analogix/fu-analogix-device.c:56:10: error: ‘G_USB_DEVICE_RECIPIENT_DEVICE’ undeclared (first use in this function)
56 | G_USB_DEVICE_RECIPIENT_DEVICE,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../fwupd-1.6.0/plugins/analogix/fu-analogix-device.c: In function ‘fu_analogix_device_receive’:
../fwupd-1.6.0/plugins/analogix/fu-analogix-device.c:96:10: error: ‘G_USB_DEVICE_DIRECTION_DEVICE_TO_HOST’ undeclared (first use in this function)
96 | G_USB_DEVICE_DIRECTION_DEVICE_TO_HOST,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../fwupd-1.6.0/plugins/analogix/fu-analogix-device.c:97:10: error: ‘G_USB_DEVICE_REQUEST_TYPE_VENDOR’ undeclared (first use in this function)
97 | G_USB_DEVICE_REQUEST_TYPE_VENDOR,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../fwupd-1.6.0/plugins/analogix/fu-analogix-device.c:98:10: error: ‘G_USB_DEVICE_RECIPIENT_DEVICE’ undeclared (first use in this function)
98 | G_USB_DEVICE_RECIPIENT_DEVICE,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
and more...
