We go to great pains to set the parent to the MAX of the child delays, but we
don't actually set the children to have the new parent value.
This means if you update the child device without the parent in the transaction
we don't always wait for all the USB devices to come back -- which is what the
acquiesce delay is designed to do.
Fixes an intermittant device test for the Wacom USB tablet.
This allows us to ignore all the delays when the device is emulated, with the
idea being to do dozens of device emulations in the CI tests.
Also, do not call fu_progress_sleep() when the device is emulated.
It turns out we do not want to know the current phase of the device, and we can
achieve the same thing tagging the GUsbDevice manually and clearing the events
at exactly the correct time.
We already had this as an inhibit, but this was not translated client-side.
We also need to propagate the problem to the bootloader device if the device
replugs during firmware update.
This only have any protective effect if we're using multiple threads -- which
we're not. Removing these unused locks does not affect startup speed, but does
drop the idle RSS by ~10kB.
In various places the code was checking if a release was set, but this would
always be false as the release was being auto-created. This was masking valid
bugs, and was confusing to have the superclass have different semantics to the
baseclass.
The baseclass is calling fu_device_build_instance_id_quirk() and when we
incorporate the device we were only copying the 'proper' instance IDs and not
the ones used for quirk matching -- which we need to match the devices that use
keys containing MODALIAS for the Plugin key to be set.
This does not serve much purpose now, but would be useful if we need to know
more about the installed PK from other plugins. If nothing else it makes the
`--verbose` output more helpful.
This allows the backend to identify the specific device for a specific phase.
For instance, there might be a pre-update runtime, a bootloader and a
post-update runtime and allowing tags to be saved to the backend object allows
us to identify each version of the same physical device.
This takes us one step closer to emulating a complete byte-perfect end-to-end
update without actual hardware installed.
Semantically it is the desire of the security attribute, not the bios
attribute, i.e. you could imagine that a specific attribute would have
to be *foo or bar or baz* for HSI-1 and *only foo* for HSI-2
Also make it easier to add possible BIOS attribute target values in
plugin code.
We want to allow all the device hotplug events to be processed before
marking the update as completed. Otherwise, we might have a situation
where we have a child device attached to a parent, where we want to
update the parent, then the child. e.g.
1. Add parent
2. Add child
3. Update parent
4. Attach parent
5. Wait for parent
...some time passes...
6. Parent re-appears
7. Update finishes, client indicates success
...child update is scheduled...
...which returns with failure as it does not exist...
8. Add child
The child should have been added *before* the update completed to avoid
the caller from needing an unspecified delay as a *workaround*.
This allows us to load sets of different host security attributes
for testing the various front end tools we have now. e.g.
sudo FWUPD_HOST_EMULATE=thinkpad-p1-iommu.json.gz fwupd
or, using a non-compressed absolute path:
sudo FWUPD_HOST_EMULATE=/tmp/test/thinkpad-p1-iommu.json fwupd
Data can be created with `./contrib/generate-emulation.py file.json`
and then can be manually modified if required. Running the script on
a file that already exists will just strip out any unneeded data, as
well as piping content into it using stdin.
As a precaution, the org.fwupd.hsi.HostEmulation attribute is added
so we do not ask the user to upload the HSI report. It also allows
the LVFS to ignore any HSI reports with this attribute for clients
that upload HSI reports regardless.
See https://github.com/fwupd/fwupd/discussions/4832
Only opt-in plugins that have been tested -- unconditionally enabling
this may cause regressions on devices like docks.
Fixes https://github.com/fwupd/fwupd/issues/4378
This allows us to make smarter policy decisions in the future on when
to show unavailable updates. It also means we can show translated
text in the frond-end clients.
Only problems the user can "fix" are enumerated. For example, opening
the laptop lid, or charging the device battery.
Allow the admin to override the inhibit(s) on devices using a similar
format to the other kvs. For instance, setting two different quirks and
clearing another could be done using:
Quirk = usb-blocked:Device defective,needs-reboot:Reboot system,not-authorized:
This also allows unsetting the quirk, which was impossible before as
`@value` was always non-NULL.
Some plugins were creating local versions (which were not attached to
the daemon progress in any way) as a workaround as they needed to do
actions that took a long time to complete.
