This means we do not do the GUID or counterpart GUID matching when adding
devices. Only an exact device-id match or when both the physical and logical
IDs match will the device be considered the 'same'.
This is to handle devices that could share the same GUIDs in both child and
parent modes where the logical ID differs.
This means we do not have to manually set the quirks for each child, and means
we get the quirk set at object construction before any instance IDs are set.
Cached metadata was not working for setting the supported flag because
of a difference in version format. The version format needs to be applied
to the device before applying the supported flag.
This particularly helps UEFI devices which set the version format to number
but in practice all metadata sets it to something different.
Fixes: #2005
Since bash-completion 2.9, it was no longer possible to override
the completionsdir through prefix. [1] In 2.10, the overridability
was re-estabilished but this time through datadir variable. [2]
This should not really matter except for developers installing the project
into a custom prefix or distros using per-package prefixes like NixOS.
[1]: 81ba2c7e7d
[2]: https://github.com/scop/bash-completion/pull/344
As a consequence, the version number is also set in the event that the silicon
or firmware app-id is not set, which also seems like the right thing to do.
The idea here is that the device would not come back after it was restarted,
and skipping the attach in the engine was only working around the fact that the
ebitdo did not split out an ->attach() function.
We can't really blame it; we only decoupled the _IS_BOOTLOADER requirement
for ->attach() recently...
The USB 2.0 controller is used as a 'backup' in case the USB 3.0 firmware fails
to start. Set USB 3 hubs as a greater priority so that the USB 2 ones do not
not get added if the USB 3 firmware is working.
Some plugins are just simple wrappers around custom GType creators and which
specific plugin created is not a good way to make a policy decision.
If this was added to work around a bug, we need to find a better solution or
fix the root cause.
These are a regression of 9e755e2a5 when devices are asleep.
However due to the current kernel and daemon architecture, logitech devices
are not checked again at any time so if the device isn't awake when
fwupd is started or the unifying dongle is plugged in it won't be present.
This will be changed in the future when the kernel has change events
associated with devices waking up.
Fixes: #1973
This was incorrect when were were adding child devices by GUID (as we should
have been setting the transaction *order*, not the plugin *priority*) and just
completely unused now we're using the ParentGuid to set the parent and not
adding a reference to the child.
This also means we do the right thing when plugins call fu_device_add_flag()
directly, instead of just from a quirk file.
For instance, now `Flags = ~updatable` is a valid and useful thing to have and
allows us to remove the `Flags = None` hack.
