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.
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!
At the moment plugins are doing this a few different ways; either looping
through the HwIds manually (e.g. flashrom) or setting a custom flag that is
checked in fu_plugin_setup (e.g. uefi-recovery).
Define a standard 'Plugin' HwId quirk to simplify plugins.
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.
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.
There are now two 'backends' of device plug/unplug events, and there is about
to become three. Rather than just adding two more vfuncs for every backend type
define common ones that all providers can use.
Also fix up the existing in-tree plugins to use the new vfunc names and filter
on the correct GType.
If any update is scheduled for SuperIO, and something changes (such as entering
S3, disconnecting the charger) before the update is installed, then the update
will get stuck.
Fixes https://github.com/fwupd/fwupd/issues/2830
The metadata might want to pass more than one location URI to the client, for
instance if the file is available from more than one HTTP mirror.
Use the noun of location to match the AppStream <artifact> naming; this is the
last place where LVFS AppStream diverges from the official specification and
it would be good to bring fwupd back into line -- although the LVFS will have
to write both elements for a very long time.
See https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html
Also: we're not changing the format of the `Uri` GVariant key to preserve both
forward and backwards compatibility of the library. We can remove it when we
next break API.
When this is done, include:
* Including the hash
* Including anything that is not ABI stable in plugins yet
Suggested-by: Simon McVittie <smcv@debian.org>
The end year is legally and functionally redundant, and more importantly causes
cherry-pick conflicts when trying to maintain old branches. Use git for history.
That giant uint64_t isn't looking so big now, and we'll want to add even more
to it in the future. Split out some private flags that are never useful to the
client, although the #defines will have to remain until we break API again.
WD19TB uses skip-restart in some cases, but not all.
The matrix of cases is enumerated in 834b28009d
Unfortunately in the most common case now - new kernel and new daemon
`skip-restart` *isn't* used. The device should be left in a `needs-activation`
state though.
Use this to skip the trigger of failed upload report.
Fixes: #2731
Asking the user for the UID mapping isn't working very well, as it requires lots
of manual handholding. It also doesn't work very well when the device vendor
does not actually have a PCI ID or if the vendor has split into two entities.
Just use the OUI address as an additional VendorID and match any of the device
IDs against any of the metadata-supplied values.
Should hopefully fix this failure:
```
Plugin thunderbolt
UpdateError device version not updated on success, 43.00 != 40.00
VersionNew 43.00
VersionOld 40.00
```
This restores compatibility when running with a new daemon and old remote files
and properly fixes all combinations of the regression casued by the commit
2f49da7f4e which appeared in the 1.5.2 release.
This would allow us to add other component types in the future, for instance a
'generic' type that adds information to the composite device.
Any generic components would need to have a requirement of 1.5.2 to avoid
showing a runtime warning when trying to get the local file details.
The logic here is that the attestation is more than just the PCR0 value, and
multiple device firmware (such as EC, ME, etc.) needs to be included to validate
the system.
By the same logic, updates for the system firmware do not tell the whole story,
and confuse HSI as a specification. Remove them.
The idea for a missing vendor-id would be that the LVFS sets the value
`NEVER_GOING_TO_MATCH` which is shown (along with the correct value) when the
user tries to **install** the firmware.
In 1.5.0 we correctly switched to filtering the devices by GUID and *then*
checking requirements before showing to the user.
In the missing vendor-id case the the poor ODM does not know why the device is
not showing up until they run the daemon in --verbose mode.
Relax the vendor-id checks when adding releases to devices, but of course leave
them in place for installing firmware. The ignore-vid-pid flag is not added
from `Install(a{sv})` and so this stays the same as before.
Checking this requirement at daemon startup meant that trust was
evaluated before releases could actually be checked.
It's only important to check at install time.
Loosen the requirement of the user ID to match root for the following
actions:
* Install release
* Activate firmware
For install release action, reject CAB files not signed by LVFS
