This behavior will prevent the dock from performing most resets until
it has been unplugged from a host system.
This significantly speeds up the perceived update duaration and prevents
data loss during update.
It's not confirmed whether EC23 or later EC will enable it.
* So only enable by a custom flag until this is confirmed.
* Custom flag will be dropped when included into stable EC release.
This functionality also relies upon the CAB file providing a message warning
user that the dock might not be usable after unplugging for up to 1 minute.
The idea is that if the user should know something about the device update
"after" it's succesfully completed then the plugin can set `UpdateMessage`
for the device and a client can show it.
An example would be a device that doesn't reboot on its own and the user
needs to power cycle it manually.
Now that there is actually support to load non-static information
(at least from fwupd perspective) it makes sense to support this
command in both tools.
The source URL allows us to comply with our various obligations when shipping
firmware built from GPL licensed sources. The details URL allows vendors to
include a link to a full HTML details page about the specific release.
Currently used structures were based on early libnitrokey definitions
(which were broken for some time). Corrected their sizes and elements,
and added tests.
Fixes#960
Signed-off-by: Richard Hughes <richard@hughsie.com>
It's currently a hodge podge of commands that can install files not
always invoking a reboot or shutdown.
Move the actual code into `fu-util-common.c` and make sure that all
`install` and `update` functions call it now.
Some aspects of the method for querying dock firmware do work in 'dell' plugin
but that is not useful for fwupd because it's incomplete.
Due to this the following error shows up in fwupd journal if run on a Dell system
when the new Dell dock is plugged in:
failed to add USB device 0bda:8153: failed to add device using on dell: invalid dock component request Query 3 0 2 4 0
Detect this scenario, and prevent showing errors in logs.
Unfortunately the previous fix (6131f5d) introduced this bug.
The code previously was actually looking for the non-zero case
which was correct, but non-obvious since `efi_guid_cmp` works like
`g_strcmp0` where a match returns zero.
So rather than revert 6131f5d make this completly explicit.
If the device is rebooted into a different shape, the plugin managing
the device may also be different.
This would be the case for plugins that just subclass the update_detach()
method, and leave to other plugins the actual required update procedure.
Affected drives should have a prominent statement in the update description,
possibly even the first line so it shows up by default in the updates panel.
