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.
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 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.
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.
Wacom has begun migrating its current Intuos product line to a new
Bluetooth chipset. This new revision uses new PIDs as well so we
need to update the quirks list.
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.
Timeout characteristics of the start/data/end commands can vary between
modules. Rather than leaving `fu_wac_module_set_feature` responsible for
setting a globally-reasonable timeout, allow the callers to specify a
locally-optimal value instead.
We only had to pile everything into the src/fuzzing/firmware directory
because honggfuzz could not cope with more than one input path.
This way each plugin is self contained and easy to copy.
Also, install the fuzzing builder objects as this fixes the installed
tests when srcdir does not exist.
Based on a patch by Jan Tojnar <jtojnar@gmail.com>, many thanks.
This allows us to override the location we load data files from, which
allows us to do more kinds of installed tests in the future.
Also, move the global data/tests content into the place that it is used
as it was getting impossible to manage.
Using fu_common_strnsplit() has the drawback that a malicious user (or
a fuzzer!) could create a file with 5,000,000 newlines, and then pass
that into any parser that tokenizes into lines. This causes millions of
tiny allocations and quickly dirties hundreds of megabytes of RSS due
to heap overheads.
Rather than splitting a huge array and then processing each line, set
up a callback to process each line and only allocate the next string if
the token was parsed correctly. This means that we don't even dup the
buffer before we start parsing, rather than allocating everything and
then failing at the first hurdle.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=38696
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.
More than one person has asked about 'why call fu_plugin_update() for a
reinstall or downgrade' and I didn't have a very good answer.
The plugin API is not officially stable, and we should fix things to be
less confusing. Use the same verbs as the FuDevice vfuncs instead.
Both the wired-only and wireless-capable versions of the CTL-4100 /
CTL-6100 will switch into "Android mode" if their string descriptors are
read too many times. A previous commit added the "no-serial-number"
flag to the wireless variants to work around this problem; this commit
adds the flag to the wired-only variants.
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 code currently assumes that the firmware sections are in sorted
order (e.g. using images_cnt as the current index). This seems to
be the case with real firmware images, but is not actually guaranteed
by anything. Rewriting the code to use the actual index from the WA
header is a little difficult so just assert this condition for now.
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)
