This makes a lot more sense; we can parse a firmware and export the same XML
we would use in a .builder.xml file. This allows us to two two things:
* Check we can round trip from XML -> binary -> XML
* Using a .builder.xml file we can check ->write() is endian safe
The idea here is to return the size of the firmware, including the header,
footer or other encapsulation. It would be expected that this value would
include the alignment if provided.
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.
Keeping *internal* API and ABI compatibility makes working with an already
complex codebase more mentally demanding than it needs to be.
Remember: plugins should be in-tree and upstream! If your out of tree plugin
stops working then it should be upstream.
The public-facing libfwupd will remain API and ABI stable for obvious reasons.
We want to make it as easy as possible for devices to refuse to update on low
battery, as this will likely be one of the WWCB requirements.
Ideally devices will check the battery level inside the firmware, but by also
providing the battery level to fwupd we can give the user a warning *before*
the update has started and without switching the device into bootloader mode.
Rather than trying to guess typos, force each plugin to register the quirk
keys it supports, so we can show a sensible warning if required at startup on
the console.
The best way of not getting something wrong is to not require it in the first
place...
All plugins now use DeviceInstanceId-style quirk matches and we can just drop
the prefix in all files. We were treating HwId=, Guid= and DeviceInstanceId= in
exactly the same way -- they're just converted to GUIDs when building the silo!
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.
NOTE that currently this is implemented for GATT characteristics only,
but can be extended to other types of objects.
Listening for property changes in a bluez characteristic requires a
long-lived connection or proxy, so this also refactors bluez device
UUIDs into a simple object that keeps the path, the proxy and the signal
id in case a callback is registered for this UUID.
An additional advantage of this is that fwupd no longer creates a
throwaway proxy object for every read and write UUID operation.
It is far too easy to forget to set FWUPD_DEVICE_FLAG_NO_GUID_MATCHING for new
plugins, and without it it all works really well *until* a user has two devices
of the same type installed at the same time and then one 'disappears' for hard
to explain reasons. Typically we only need it for replug anyway!
Explicitly opt-in to this rarely-required behaviour, with the default to just
use the physical and logical IDs. Also document the update behavior for each
plugin to explain why the flag is being used.
This allows you to have two identical Unifying plugged in without one of them
being hidden from the user, at the same time allowing a HIDRAW<->USB transition
when going to and from bootloader and runtime modes.
This removes the workaround added in 99eb3f06b6.
Fixes https://github.com/fwupd/fwupd/issues/2915
This is typically a Linux sysfs path or USB platform ID and is used in a
different way to the physical ID. The physical ID is only set for some devices
after setup() and depends on the subsystem list, and this would not be defined
for devices that do not match a plugin.
This also fixes an regression where the FuDeviceList fails to match the new
FuUdevDevice device in fu_device_list_get_by_guids_removed() and instead
silently gets 'fixed up' only if FWUPD_DEVICE_FLAG_NO_GUID_MATCHING is not set.
This also allows us to move the various backends device caches to FuBackend as
we now have a suitable ID that is for just the backend to use.
If the user explicitly specifies the device-id then we do not do the front-end
filtering. If the device detaches without being able to attach then the hardware
could be left in the bootloader state.
See https://github.com/fwupd/fwupd/issues/2926#issuecomment-784234180
References to opt_variant and val_variant are sunk in a subsequent
variant creation and consumed by g_dbus_proxy_call_sync. They don't need
to be freed in this context.
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.
fu_udev_device_ioctl() interprets the return value of ioctl() as the
error cause and generates a misleading error message (permission
denied).
Fix it to use errno for error checking and reporting.
