Archives uploaded to LVFS will have checksums written by hexdigest
and be set to lowercase, but hand generated archives this may not
be true.
For maximum compatibility with the most fwupd versions they should
be written in lowercase, but in case they aren't, convert to lowercase.
Reference https://github.com/fwupd/firmware-lenovo-thinkpad/issues/145
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.
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.
The CustomFlags feature is a bit of a hack where we just join the flags
and store in the device metadata section as a string. This makes it
inefficient to check if just one flag exists as we have to split the
string to a temporary array each time.
Rather than adding to the hack by splitting, appending (if not exists)
then joining again, store the flags in the plugin privdata directly.
This allows us to support negating custom properties (e.g. ~hint) and
also allows quirks to append custom values without duplicating them on
each GUID match, e.g.
[USB\VID_17EF&PID_307F]
Plugin = customflag1
[USB\VID_17EF&PID_307F&HUB_0002]
Flags = customflag2
...would result in customflag1,customflag2 which is the same as you'd
get from an enumerated device flag doing the same thing.
Add a FuDevice->ready() vfunc that is run after ->setup()
This allows plugins to perform setup actions that require quirk matches
after the instance IDs have been converted. This allows us to also
remove FuVliDevice->setup() as the ordering chain has been broken.
There are two USB-3 hubs internally (with the same VID&PID), and the
MSP430 is only attached to the top-level one.
Fixes https://github.com/fwupd/fwupd/issues/3366
Before this change calling FuUsbDevice->open() opened the device, and
also unconditionally added various GUIDs and InstanceIDs which we
normally do in setup.
Then fu_device_setup() would call the FuSubclass->setup() vfunc which
would have no way of either opting out of the FuUsbDevice->setup()-like
behaviour, or controlling if the parent class ->setup is run before or
after the subclass setup.
Split up FuUsbDevice->open() into clear ->open() and ->setup() phases
and add the parent class calls where appropriate.
This means that ->setup() now behaves the same as all the other vfuncs.
There were some compilation warnings (one actual error) and possibility
to use incorrect efivar library.
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Until gi-docgen is declared stable support either of them.
This effectively means that hand builds and CI builds will use
gi-docgen, but distro builds use gtk-doc-tools.
Shadow FwupdDevice::parent with FuDevice::parent so that we *also* set
the context and composite ID.
This means we can always install all components of the Lenovo docks.
There is no Manager object, so block devices must be discovered
manually.
Additionally, Type field contains FS name rather than its MBR ID in
hex form or a GPT GUID.
Signed-off-by: Richard Hughes <richard@hughsie.com>
