This allows plugins to load an archive supplied as the 'deliverable' of the
cabinet archive. This means plugins can bundle up a set of images in a cross
platform way, for instance adding boot.img+os.img+manifest.xml into a zip file,
rather than having to (ab)use the DfuSe file format or deal with libarchive
directly.
Otherwise this would cause fwupd to sit in an endless loop when providing a bad
image.
This additional enum is only available in EC16, but since it doesn't break existing
API on older EC images, don't bump minimum requirement to EC16 yet.
This metadata key is now unnecessary, as firmwares are expected to set the
version format in the metadata.
If the metadata is missing, the LVFS allows a per-vendor default for non-semver
release versions which is now unconditionally set in metadata.
Plugins are allowed to 'opt-out' of this behaviour using _RULE_INHIBITS_IDLE.
This should be used where waking up the hardware to coldplug is expensive,
either from a power consumption point of view, or if other artifacts are going
to be seem -- for instance if the screen flickers when probing display devices.
This functionality is also inhibited when the actual upgrade is happening,
for obvious reasons.
Admins can turn off this auto-sleep behaviour by editing the daemon.conf file.
Fixes https://github.com/hughsie/fwupd/issues/417
This speeds up matching for GUIDs by about 90%, taking the query from 3.17ms to
about 0.33ms on my Thinkpad. This is more important for slow ARM hardware,
where strcmp() is more expensive than on x64.
This matches what a lot of other projects do, and means we can easily format
the release notes back into NEWS format, but also into HTML and Markdown.
This also means we can show the correct update description in gnome-software
when building a flatpak, rather than falling back to the generic project
description.
We load the Thunderbolt controller firmware to see if the controller is in
native mode, as this changes the GUID. If the controller is asleep the firmware
is not cached by the kernel and it can take more than 4 seconds to read out
504kB of firmware.
We only need the first two 64-byte chunks, so only read what is required.
This speeds up fwupd starting substantially, and also means we don't have to
allocate a giant chunk of heap memory just to inspect one byte.
Fixes: https://github.com/hughsie/fwupd/issues/848
The same information can be seen in `/usr/libexec/fwupd/fwupdtool hwids` and
for most users verbose mode is turned off -- so we're doing all those expensive
allocations for nothing.
This means we don't have to have all the thousands of GUIDs as tiny allocated
strings being passed around to all plugins in a GPtrArray.
This also reduces our heap usage by about 6%.
These are set from the AppStream metadata and are specific to the firmware
release.
If not provided, the install duration falls back to the per-device duration
values which can be set in the quirk files.
This fixes a regression in 1.2.0 -- the XML files are metainfo.xml files and
thus don't have the surrounding <components> parent tag.
We also want to return XML without the <description> wrapper node, so switch to
including siblings instead.
If the FuDevice is changed during a replug then the `UPDATE_STATE_SUCCESS` will
not be stored on the current FuDevice, which means we store an update-state of
`unknown` to the history database.
Which means we get no success or failure reports, which is bad.
This means we are storing the distro that was used to perform the update,
rather than the distro that was used to do the upload.
Fixes https://github.com/hughsie/fwupd/issues/838
We want the XML to look like:
<custom>
<value key="fwupd::RemoteId">lvfs</value>
</custom>
not:
<custom>
<fwupd::RemoteId>lvfs</fwupd::RemoteId>
</custom>
Also, fix the XPath query string to actually match the container checksum, and
actually save the custom node to the builder source.
This fixes a regression in 1.2.0 where no reports could be uploaded.
If the poll source is scheduled just at the right time, we might only get 8x
'10ms ticks' in a 100ms window. This fixes an occasional build failure on
slower hardware and in CI.
The current libxmlb dependency requires this and when run in subproject
mode will cause failures otherwise.
Also bump the snap to use meson 0.47.2 to fix snap build due to this
failure.
The ids clash with the Xbox controller ids. This makes the Xbox controller unusable since fwupd unloads the device just after connecting it and fails to update it not being a 8bitdo device.
As seen here: https://github.com/paroj/xpad/issues/114
Since dell_dock is the priority plugin for MST flashing the VMM5331
no need to do delayed callbacks anymore.
When the dell_dock plugin bumps to EC 15 being the minimum requirement
more code can also be dropped.
1. Since board ID in synapticsmst.quirk is different based upon how
the board ID is read, don't whitelist it in `write_firmware`
2. Allow using `--force` with `fwupdmgr` or `fwupdtool` to override
board ID check.
3. Allow using custom flag `ignore-board-id` to ignore board IDs.
This will be the default for EVB boards and can be used in the event
of a factory mistake as well.
4. Move the EVB board IDs into their own synapticsmst_evb.quirk.
This file will not be installed by default (So EVB boards are only
functional when manually installed).
