This also means we do the right thing when plugins call fu_device_add_flag()
directly, instead of just from a quirk file.
For instance, now `Flags = ~updatable` is a valid and useful thing to have and
allows us to remove the `Flags = None` hack.
This is nice in theory, until you need to look at the bootloader status of the
parent, or of a different device entirely. Handle this in plugins for the few
cases we care about and stop setting or clearing IS_BOOTLOADER manually just to
get the vfuncs to be run.
Note: I do not think we want to use cleanup() for attaching devices not in
bootloader states -- as cleanup is only run at the end of the composite update.
We use the ParentGuid quirk key to logically 'tie-together' different discrete
devices into one logical device, for instance making the USB soundcard in a hub
the child of the USB controller on the same PCB.
Setting the discrete child is sometimes correct, for instance when rebooting
the hub, the audio device also goes away -- but it's also sometimes wrong.
If we set the child for a discrete device and the parent does *not* go away
then we get to a situation where the child reference may no longer be valid
if it comes back as a different object.
When we try to remove this no-longer-valid device with the removal timeout the
daemon segfaults. This is realy bad.
Continue to allow using fu_device_add_child() in plugins, where we know the
child lifecycle is is matched by the the parent. In the engine just set the
parent ID directly and let the client use this information to show the tree of
logical devices correctly. There's no benefit to setting up the children as
referenced objects anyway.
Sometimes plugins need to retry various commands send to hardware, either due
to unreliable transfers (e.g. using USB bulk) or from slightly quirky hardware.
Between them they seem to get various things wrong; either the error messages
are repeated and thus difficult to parse, or they just get the memory handling
of `g_propagate_prefixed_error()` wrong.
Providing sane helpers we can reduce the amount of boilerplate. Additionally
we can support a 'reset' function that can try to automatically recover the
hardware for specific error domains and codes.
Sometimes we only want to add the instance ID to get the quirk matches, and it
is confusing to see the "fake" IDs in the 'fwupdmgr get-devices' output.
A Jcat file can be used to store GPG, PKCS-7 and SHA-256 checksums for multiple
files. This allows us to sign a firmware or metadata multiple times (perhaps
by the OEM and also then the LVFS) which further decentralizes the trust model
of the LVFS.
The Jcat format was chosen as the Microsoft catalog format is nonfree and not
documented. We also don't want to modify an existing .cat file created from WU
as this may make it unsuitable to use on Windows.
More information can be found here: https://github.com/hughsie/libjcat
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 do not ->open() the device (e.g. because it uses a parent device to proxy
writes) then the child never gets a DeviceID which causes all kinds of issues.
When CPU microcode is distributed it typically is versioned in
hexadecimal in all tools. Converting it to any of the existing version
formats provides an unexpected result that requires converting back to
hexadecimal.
If the measurements are missing but it's a UEFI system, it's a good indication
that the user has secure boot turned off.
Notify the user on the UEFI device through a non-fatal `UpdateMessage`
To accomplish this, move fu-uefi-vars into the plugin library for other plugins to use
Use xb_builder_source_add_simple_adapter instead
xb_builder_source_add_adapter to avoid sniffing MIME type for output xml
contents
Signed-off-by: Daniel Campello <campello@chromium.org>
Change-Id: I123c37339720b5844351f85a5aeb9cec4928785c
Replace fu_common_cab_build_silo() with an actual GObject that can hold parsing
state. This cleans up the code a lot, and means we can add additional
functionality in the future without breaking ABI or API.
The long term plan is to verify the metadata and payload signatures when
parsing FuCabinet, rather than much later in _check_requirements().
This of course requires passing in a keyring context (which we don't yet have)
and would mean we can stop setting the various confusing 'fwupd::ReleaseBlob'
XbNode extra data.
No logic changes for now, just a lot of moving things into sane places.
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.
In 1de7cc we checked the version format when checking for update, but there are
many other places that are doing verfmt-insensitive comparisons. For instance,
the predicates in <requires> all fail if the device version format is plain.
his breaks updating some NVMe drives where the `ne` requirements are not
semantic versions.
To avoid trying to catch all the bugs in different places, and in case we have
a future verfmt that should be treated another way, refactor this out in to a
common function and deprecate the old function.
Sometimes the plugin will want to influence the subclassed device, for instance
by reading a per-plugin config file. At the moment there's no way to do this,
as even _device_registered() is explicitly designed for devices *not* created
by the plugin itself.
Even if _device_registered() was changed to include the plugin creating the
object it would still happen well after the device has done _probe() and/or
_setup() and would probably be too late to do anything useful.
In some hardware there are two identical USB hubs with different firmware.
One is upstream, and one is downstream, making up to 7 user-available ports.
Use the 'removable' bitfield to target the proper firmware to the correct
device, on the logic that the setting will be different on upstream (removable)
and downstream (non-removable, as on the same PCB) hubs.
