Some plugins were creating local versions (which were not attached to
the daemon progress in any way) as a workaround as they needed to do
actions that took a long time to complete.
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.
Wacom is beginning to integrate a new Bluetooth chipset in their
devices. This chipset uses a somewhat different flash protocol
and requires the creation of a new fwupd module. Chipsets using
this new protocol are identified in the firmware descriptor with
ID 0x06, leading to our choice of module name: "bluetooth-id6".
The new chipset is first appearing in a minor update to the Wacom
Intuos (CTL-4100WL/CTL-6100WL) line. These devices do not support
the firmware descriptor interface, requiring us to statically assign
it as a module in the legacy codepath if any Bluetooth support is
found. This clutters the output of the `get-devices` command but the
update CAB files ensure the correct module is used depending on PID.
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.
While the modern firmware interfaces report their version numbers in
big-endian form, reading the legacy Bluetooth module version via the
FU_WAC_REPORT_ID_GET_FIRMWARE_VERSION_BLUETOOTH report requires us to
actually parse a little-endian value. This difference was overlooked
when making changes to the version parsing code in commit 50a4ec70e6.
This commit restores the proper interpretation.
Fixes: 50a4ec70e6 (wacom_usb: Firmware versions are packed BCD, not "decimal")
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.
The value of `self->firmware_index` is not valid until we call
`fu_wac_device_ensure_firmware_index`. Because of this, we would always
request the firmware for index 0. If that slot is currently active then
our attempt to program it will fail since the pages are write-protected.
Annoyingly the only signs that something has gone wrong are that the
flash completes almost instantly and the firmware version never changes.
To fix this we re-order our usage of the variable to be after it
becomes valid. We also add a noisy failure message that is triggered
if no blocks are written.
Fixes: 7afd7cba0d ("Use FuFirmware as a container for firmware images")
Version numbers used by Wacom firmware are typically coded as packed BCD
numbers. The minor version numbers are typically rendered with leading
zeros in the wild, though it appears fwupd doesn't follow this same
visual convention.
Some example versions:
* { 0x00, 0x05 } --> 0.05 (Wacom rendering) / 0.5 (fwupd rendering)
* { 0x01, 0x01 } --> 1.01 (Wacom rendering) / 1.1 (fwupd rendering)
* { 0x01, 0x23 } --> 1.23 (Wacom rendering) / 1.23 (fwupd rendering)
Fixes: 872ec1b68f (Add an experimental plugin to update some new Wacom tablets)
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.
Quite a few plugins use HID commands to communicate with the hardware. At the
mement we have ~6 implementations of SET_REPORT and are soon to add one more.
Move this into common code.
If we say that the version format should be the same for the `version_lowest`
and the `version_bootloader` then it does not always make sense to set it at
the same time.
Moving the `version_format` to a standalone first-class property also means it
can be typically be set in the custom device `_init()` function, which means we
don't need to worry about *changing* ther version format as set by the USB and
UDev superclass helpers.
Some plugins have devices with more than one protocol. Logically the protocol
belongs to the device, not the plugin, and in the future we could use this to
further check firmware that's about to be deployed.
This is also not exported into libfwupd (yet?) as it's remains a debug-feature
only -- protocols are not actually required for devices to be added.
There are several subtle bugs in various places in fwupd caused by not treating
user-provided offsets into buffers as unsafe. As fwupd runs as root we have to
assume that all user firmware is evil, and also that devices cannot be trusted.
Make a helper to put all the logic into one place and convert all users.
In many plugins we've wanted to use ->prepare_firmware() to parse the firmware
ahead of ->detach() and ->write_firmware() but this has the limitation that it
can only return a single blob of data.
For many devices, multiple binary blobs are required from one parsed image,
for instance providing signatures, config and data blobs that have to be pushed
to the device in different way.
This also means we parse the firmware *before* we ask the user to detach.
Break the internal FuDevice API to support these firmware types as they become
more popular.
This also allows us to move the Intel HEX and SREC parsing out of the dfu plugin
as they are used by a few plugins now, and resolving symbols between plugins
isn't exactly awesome.
This leads to madness, as some formats are supersets of the detected types,
e.g. 'intel-me' is detected as 'quad' and 'bcd' is detected as 'pair'.
Where the version format is defined in a specification or hardcoded in the
source use a hardcoded enum value, otherwise use a quirk override.
Additionally, warn if the version does not match the defined version format
The checksum is now stored as the very last flash descriptor, so we need to pad
the SREC data to include the 'missing' data range. As we're doing that, we
should optimize like the Wacom updater does and skip writing descriptors that
are unused.
