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 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.
This was only true by accident. We'll need another fix for the LVFS to
add the missing NUL to restore compatibility for older clients.
Fixes https://github.com/fwupd/fwupd/issues/3533
The raw SMBIOS tables that Linux exposes in /sys/firmware/dmi
are restricted to being readable by root only. If running as
non-root access is still permitted by fields that have been
pre-parsed by the kernel in /sys/class/dmi, most of which are
world-readable. This allows the daemon to load most HWIDs even
if running as a non-root user, as is done on Chromium OS.
The benefit of using the proxy device is that we can 'use' the proxy
device for device access, but 'report' the progress on the passed
FuDevice instance.
This means the front-end reports the device status correctly when
updating composite devices that us proxies.
The comment always said we should move it to the daemon if another
plugin started doing this, and that is now.
I assume at some point we forgot to remove it when converting an object
from FINAL to DERIVABLE and the anti-pattern just got copied around the
codebase...
The "return error and hope the client resubmits the firmware again"
pattern is clunky. There are two plugins doing this now, and about to
be one more.
This adds FwupdRequest which provides a structured way of asking the
user to perform an action, e.g. to replug the device or to press a
special key or button.
This replaces much of the UpdateMessage and UpdateImage API although
it is still used internally. Clients capable of processing the new
DeviceRequest signal should add REQUESTS to their feature flags.
Also, this allows us go back to the old meaning of _NEEDS_BOOTLOADER,
which was "needs rebooting into a bootloader mode" rather than the
slightly weird "user needs to do something and resubmit request".
The kernel allows configuring this, and certain plugins will use this
path to be able to load firmware in the kernel driver through runtime,
but to flash to the device.
At the moment the device list auto-removes children when the parent is
removed. This was originally working around the bug that the child
devices had no backend ID, and thus were not matched like the parent
in fu_engine_backend_device_removed_cb() and removed automatically.
Using the workaround means that the children are potentially removed
before the parent depending on the order of the device list -- which
might be modified by replug events.
I think the old cleanup is probably an anti-pattern, and going forward
composite devices should probably define _NO_AUTO_REMOVE_CHILDREN but
we don't want to change this behaviour for plugins already expecting
the old flow, or for devices with no parent backend IDs.
There are now multiple plugins using drm_dp_aux_dev interface which
may potentially be combined with an amdgpu. Prevent exercising this
interface with any plugin using DP aux unless a new enough kernel is
installed.
If adding an entry into the class function table then the padding has
to be decremented unless the SO version is incremented.
Fixes out-of-tree plugins failing to load with:
GLib-GObject: Specified class size for type 'FuXxxDevice' is smaller
than the parent type's 'FuDevice' class size
This means we don't display something like 'Logitech Logitech Product'
when showing the devices on one line.
This is now required in two plugins so move it to common code. Also
support setting the properties in either order to prevent regressions
when using the device name as part of the instance ID.
