This also lets us remove the call to dfu_device_wait_for_replug() which was
causing a deadlock due to unsafe main context usage. Splitting the code allows
us to use the device list to watch for replug, without adding even more Jabra-
specific plugin code to the DFU plugin.
Looking at this with a 40,000ft view, the Jabra runtime really doesn't have
much in common with DFU and the reason it was originally all lumped together
was that the daemon couldn't "change" plugins between detach and update.
It's unfortunate that we have to include a sleep() in the DFU code after the
DFU probe, but this is specified by Jabra themselves. Attempting to open the
device without waiting reboots the hub back into runtime firmware mode, so we
can't even retry the failing setup action.
During startup we do 1898 persistent allocations to load the quirk files, which
equates to ~90kb of RSS. Use libxmlb to create a mmap'able store we can query
with XPath queries at runtime.
Some devices don't set the CAN_DOWNLOAD attribute in their runtime descriptor.
Rather than quirk these devices just assume that all DFU devices with a DFU
interface can download in DFU mode. The logic being, why would they expose a
runtime DFU interface if they can't download new firmware in DFU mode...
Devices like the DW1820A that are currently blacklisted because of broken DFU
support will remain blocked with this change.
This was a new file format to help out an OEM, but they didn't actually use it.
If we do need it in the future, it would some back as a src/ helper, not in
plugins/dfu.
We don't support any hardware that actually uses this proposed standard, and
nowadays there is much better public-key encryption people can easily use.
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.