This regressed in 1.5.5 when we migrated FWUPD_DEVICE_FLAG_MD_SET_VERFMT
into FU_DEVICE_INTERNAL_FLAG_MD_SET_VERFMT and forgot to copy the system
device internal flags.
Quite a few plugins are using a FuDeviceLocker to detach then attach in
the error path, and finding them isn't easy as we explicitly cast to a
FuDeviceLockerFunc.
For sanity, just provide both symbols so we can do the right thing in
both cases. It seems like a sensible thing to allow.
Fixes https://github.com/fwupd/fwupd/issues/3771
It's actually quite hard to build a front-end for fwupd at the moment
as you're never sure when the progress bar is going to zip back to 0%
and start all over again. Some plugins go 0..100% for write, others
go 0..100% for erase, then again for write, then *again* for verify.
By creating a helper object we can easily split up the progress of the
specific task, e.g. write_firmware().
We can encode at the plugin level "the erase takes 50% of the time, the
write takes 40% and the read takes 10%". This means we can have a
progressbar which goes up just once at a consistent speed.
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.
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".
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.
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
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.
