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.
Applying updates to my new P1G3:
* schedule the update in fwupd
* boot into the BootNext
* apply the capsule with RT->UpdateCapsule
* reboot with RT->ResetSystem
Except the firmware updater EFI binary then wasn't running. The ESRT
last_attempt_status comes back as Success on the reboot.
Disabling the UX capsule made the update apply correctly each and every
time. Until we can work out what models are affected, use a per-vendor
quirk to avoid delaying the release.
This CL moves the battery information retrieval into a new function,
called "fu_plugin_powerd_callback()", which returns the information in a
struct.
This information is then used in fu_plugin_update_prepare() for battery
checks. There is also a g_timeout_add() function being created in
fu_plugin_startup() in order to enable the plugin to repeatedly send a method
call to powerd.
fu_plugin_update_prepare is removed as its functionality is now handled
by src/fu-engine.c
We have the property notification in place now so that the update state
is saved correctly to the database on error.
This helps with debugging as we don't need to explain (to ourselves?!)
why the device is marked as failed even though nothing has run.
If we swap from runtime -> bootloader -> runtime we need to copy the
update state in each step even if we're just switching the swapping the
runtime device.
This regressed, as we optimized away the call to fu_device_list_replace.
1. Let the user know what commit it's reformatting in stdout
2. Add a debug mode to show the command that was launched
3. Fix output of errors
4. Allow the user to specify starting commit in an argument
In hindsight connect() was a poor choice of name as this is hardcoded
as the GObject parent method for signal attachment. It's not actually
required when using the sync API in Python as it's called when required.
The LVFS is now adding an artificial NUL to the metainfo data to work
around a possible buffer over-read on old fwupd versions. This breaks
new code that reads the XML buffer using xb_builder_source_load_bytes
as GLib then tries to parse the final NUL byte.
As `xmllint` actually ignores the trailing NUL, we should as well.
