Decrease the GUsb polling interval when any of the devices is in
`WAIT_FOR_REPLUG` on when running on Windows. Any device that can
re-enumerate much faster than the default 1000ms may be missed and the
detach may fail.
Linux doesn't have this problem as it has `LIBUSB_CAP_HAS_HOTPLUG`.
Now all plugins define custom GTypes in the _init() vfunc, and so
there's no need to actually probe devices to just get access to those.
This means you can get results from `fwupdtool get-firmware-types`
about two orders of magnitude quicker.
We need to load the quirks (respecting NO_CACHE), then load the SMBIOS,
and only then match the hwids using the quick database.
This means we don't get a console warning when using fwupdtool commands
as a non-root user.
This allows us to replace the 'dfu-tool replace' with a much more
controlled 'fwupdtool firmware-patch' command that patches at a set of
specific offsets.
Drop in the new functionality into the existing firmware ->write()
vfuncs so that the image headers, footers and/or checksums are correct.
Most vendors do not mirror the firmware update to an external display,
and some don't behave correctly when the lid is shut and the machine is
docked. Add this quirk just for Lenovo for now.
Fixes https://github.com/fwupd/firmware-lenovo/issues/181
This change offline ports in the host controller
for retimers to enumerate in the NDA case.
-offline and rescan usb4 ports
-this enable enumeration of the retimers
-updates nvm to the enumerated retimers
-online usb4 port this will de-enumerate retimers
BUG=b:187506425
TEST=emerge-volteer fwupd
Signed-off-by: Kranthi Kuntala <kranthi.kuntala@intel.corp-partner.google.com>
Install or downgrade firmware on all devices to make the system match
a well known set. This allows two things:
* Factory recovery where a device in the field has been upgraded
* Ensuring a consistent set of tested firmware for a specific workload
A tag is assigned either during upload or added post-upload on the LVFS
which is included in the metadata. A single firmware can be marked with
multiple tags, and tags can be duplicated for different firmwares.
Proxying the values is firstly inefficient, in that there were only
three functions in fu-engine.c that did not already have FuProgress
objects passed to them.
Secondly, processing the 'status' values from the engine meant that we
reset the percentage value to 0 for a split second, which made the
progress bar jump back to zero for one frame making it flicker.
Just make it all simpler and use FuProgress directly.
