MATEKF722SE has unconvetional behavior for dfu protocol, where the sector size
isn't specified and sector type is shiffted left by 1. This happens only for
one sector.
Sector parsing from MATEKF722SE:
* `016Kg`
* `64Kg`
* `128Kg`
* `048 e`
* `528e`
* `004 e`
Doing this unconditionally means we accidentally 'bleed' one device mode into
another in a non-obvious way. For instance, a device might have two operating
modes with different GUIDs. If firmware is supplied for both modes in the same
cabinet archive then we might accidentally match the 'wrong' firmware when
the daemon has observed a mode switch and added the counterpart GUIDs.
We only really need the counterpart GUIDs when switching between Jabra, 8bitdo
and DFU devices where the DFU bootloader VID:PID is not manually tagged with
`CounterpartGuid` in a quirk file. In the general case lets keep it simple to
avoid difficult to find bugs.
The m-stack DFU quirk also requires that we get the runtime status so that the
USB_DFU_SUCCESS_FUNC callback gets called. We were doing this by accident
before, and since switching to the FuDevice subclass this was dropped.
The dfu_device_refresh_and_clear() function is safe to call on a device which
does not have a working runtime interface.
We don't actually need either of the things it provides (looking up in source
and built, and converting to an absolute path) so just replace it with
g_build_filename() instead.
This also has the advantage that it does the right thing on Windows.
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.
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.
