Now incorporate is fixed to copy across the properties we need in the
superclass, we don't need to do the subclass ->probe().
Note, we still need to do the subclassed ->probe() when using
FU_UDEV_DEVICE_FLAG_VENDOR_FROM_PARENT or when looking at properties
on the parent device.
This also removes the spurious 'already set GType to FuVliUsbhubDevice,
ignoring FuVliUsbhubDevice' messages when running the daemon.
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.
We now have 9 different plugins all using this functionality, and we're
about to add one more. Move this into common code so that all the
plugins are using the same endian and bufsz-safe versions.
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 allows us to 'nest' firmware formats, and removes a ton of duplication.
The aim here is to deprecate FuFirmwareImage -- it's almost always acting
as a 'child' FuFirmware instance, and even copies most of the vfuncs to allow
custom types. If I'm struggling to work out what should be a FuFirmware and
what should be a FuFirmwareImage then a plugin author has no hope.
For simple payloads we were adding bytes into an image and then the image into
a firmware. This gets really messy when most plugins are treating the FuFirmware
*as* the binary firmware file.
The GBytes saved in the FuFirmware would be considered the payload with the
aim of not using FuFirmwareImage in the single-image case.
Devices may want to support more than one protocol, and for some devices
(e.g. Unifying peripherals stuck in bootloader mode) you might not even be able
to query for the correct protocol anyway.
This allows a device subclass to call the parent method after doing an initial
action, or even deliberately not call the *generic* parent method at all.
It also simplifies the plugins; you no longer have to remember what the plugin
is deriving from and accidentally clobber the wrong superclass method.
At the moment FuChunks are sometimes mutable, and sometimes immutable, and it's
all a bit too low level for comfort.
Before we can do any kind of optimisation or verification we need plugins to
stop reading directly from the C structure. The aim here is to make FuChunk
optionally mutable without making assumptions about the memory model, and also
to be able to introspect it for the docs.
Asking the user for the UID mapping isn't working very well, as it requires lots
of manual handholding. It also doesn't work very well when the device vendor
does not actually have a PCI ID or if the vendor has split into two entities.
Just use the OUI address as an additional VendorID and match any of the device
IDs against any of the metadata-supplied values.
1. Check FW in bootloader mode, need send reset command to firmware.
2. IAP Type register parameter is defind as how many bytes/page to be written.
3. Write IAP Type function in detach function.
4. Remove IAP Type function in setup function.
5. Modify page format for i2c-device
6. Modify firmware bin file size.
7. Modify firmware update flow when the firmware in bootloader mode.
8. Add another instance ID which corresponds to the IC type & module ID
* `ELANTP\ICTYPE_09&MOD_1234`
9. Add Lenovo ThinkPad X1 nano gen1 to elantp.quick
10. Add recovry device - lenovo thinkpad x1 nanao gen 1
11. Add elan touchpad device - vid:04f3 pid:314f
12. Set the firmware version when the firmware is incorrect.
