Some Poly usb devices report zero in the bwPollTimeout field of
GET_STATUS request. The host can issue the next DFU_DNLOAD
request immediately without any delay.
Introduced a private flag to skip the default DNLOAD timeout
(5ms) fix. It could remarkably reduce the firmware downloading
time taking into account the large firmware (more than 500MB).
gi-docgen requires 3.3.3 or later, but some of the distro packages
are too old. Upgrade them to make the default
```
meson build
```
work out of the box
Allow fwupd to use the BatteryStatePoll signal instead
of the GetBatteryState method call so that fwupd does
not need to run a timer itself and is automatically updated
on power connect/disconnect.
Change-Id: I81aad6a5933fa267473a83d1b97f4638235b155a
* dell-dock: open usb4 device in the activate call, and leave early
* trivial: read history earlier, at least before plugin register
* dell-dock: activate usb4 device exclusively if it needs activation
All the other vfuncs have 'plugin, device, flags' but prepare and
cleanup vfuncs being 'plugin, flags, device' order has been triggering
my OCD for the last few years.
We've just broken the symbol names, so it's the right time to fix this.
Module may not have been re-probed and exposed in MM when the FW version was successfully obtained, which leads to the report that failed to get device after update. In fact, FW has been uodated successfully, it needs to add 150s to wait for the module to be re-probed and exposed in MM.
Signed-off-by: Jarvis Jiang <jarvis.w.jiang@gmail.com>
Limits copying the get version response payload to the size of the out buffer.
Devices that return a larger payload pack the necessary version information at
the beginning of the payload.
Fixes: #1661
More than one person has asked about 'why call fu_plugin_update() for a
reinstall or downgrade' and I didn't have a very good answer.
The plugin API is not officially stable, and we should fix things to be
less confusing. Use the same verbs as the FuDevice vfuncs instead.
The RTD2141B has the same update protocol as RTD2142, but the Chromebook
targets that use it require us to find the drm_dp_aux_dev i2c channel
differently because the AMD display driver doesn't give each output a
unique name in sysfs, so it must be found by walking sysfs from the drm
device representing an output.
Change-Id: Icb6c1a40b8a62af72808d68a0a69555810abc272
Based on a patch by Twain Byrnes <binarynewts@google.com>, many thanks.
Use this to test:
sudo FWUPD_TEST_PLUGIN_XML="<config><delay_decompress_ms>100</delay_decompress_ms></config>" \
./src/fwupdtool --plugins test get-devices -v
Create and destroy /run/lock/power_override/fwupd.lock.
This file will hold the contents of getpid (), which will
stop the device from being suspended while the file exists.
The file will be created and written just before the
update is put into motion and be destroyed once the update
finishes, or upon restart in case of catastrophic failure.
Change-Id: If8dd17b0358862a842c9589e11ed0de12d852797
This speeds up fu-self-test, but more importantly fixes a intermittent
'ninja check' failure when a host USB device disconnects at exactly the
wrong time.
The FuUsbBackend code is unusual in that the setup() code sets up a
context (with a thread) which takes up to 2 seconds to timeout.
We don't want to show the big warning about the missing ESRT on server
hardware that is managed by a BMC:
WARNING: UEFI capsule updates not available or enabled in firmware setup
See https://github.com/fwupd/fwupd/wiki/PluginFlag:capsules-unsupported for more information.
