Rather than trying to guess typos, force each plugin to register the quirk
keys it supports, so we can show a sensible warning if required at startup on
the console.
The best way of not getting something wrong is to not require it in the first
place...
All plugins now use DeviceInstanceId-style quirk matches and we can just drop
the prefix in all files. We were treating HwId=, Guid= and DeviceInstanceId= in
exactly the same way -- they're just converted to GUIDs when building the silo!
This means we can use the standard ->set_quirk_kv() vfunc rather than using
FuQuirks directly with a custom group. Also use a plugin prefix for quirk keys.
At the moment plugins are doing this a few different ways; either looping
through the HwIds manually (e.g. flashrom) or setting a custom flag that is
checked in fu_plugin_setup (e.g. uefi-recovery).
Define a standard 'Plugin' HwId quirk to simplify plugins.
Devices may want to support more than one protocol, and for some devices
(e.g. Unifying peripherals stuck in bootloader mode) you might not even be able
to query for the correct protocol anyway.
NOTE that currently this is implemented for GATT characteristics only,
but can be extended to other types of objects.
Listening for property changes in a bluez characteristic requires a
long-lived connection or proxy, so this also refactors bluez device
UUIDs into a simple object that keeps the path, the proxy and the signal
id in case a callback is registered for this UUID.
An additional advantage of this is that fwupd no longer creates a
throwaway proxy object for every read and write UUID operation.
This patch is adding the fwupd wrapper for Qubes.
The wrapper provides fwupd functionalities for Qubes R4.1.
It creates three packages (two RPMs and one Debian package):
fwupd-qubes-dom0 (RPM)
fwupd-qubes-vm (RPM)
fwupd-qubes-vm-whonix (deb)
More information about the wrapper could be found in the
contrib/qubes/README.md
Signed-off-by: Norbert Kamiński <norbert.kaminski@3mdeb.com>
This is effectively a lot of dead code.
* The minimum requirements for this feature are EC 00.00.00.23 and Hub2 1.42.
* "A00" docks shipped with EC 01.00.00.00 and Hub2 1.47
It is far too easy to forget to set FWUPD_DEVICE_FLAG_NO_GUID_MATCHING for new
plugins, and without it it all works really well *until* a user has two devices
of the same type installed at the same time and then one 'disappears' for hard
to explain reasons. Typically we only need it for replug anyway!
Explicitly opt-in to this rarely-required behaviour, with the default to just
use the physical and logical IDs. Also document the update behavior for each
plugin to explain why the flag is being used.
This allows you to have two identical Unifying plugged in without one of them
being hidden from the user, at the same time allowing a HIDRAW<->USB transition
when going to and from bootloader and runtime modes.
This removes the workaround added in 99eb3f06b6.
Fixes https://github.com/fwupd/fwupd/issues/2915
This is typically a Linux sysfs path or USB platform ID and is used in a
different way to the physical ID. The physical ID is only set for some devices
after setup() and depends on the subsystem list, and this would not be defined
for devices that do not match a plugin.
This also fixes an regression where the FuDeviceList fails to match the new
FuUdevDevice device in fu_device_list_get_by_guids_removed() and instead
silently gets 'fixed up' only if FWUPD_DEVICE_FLAG_NO_GUID_MATCHING is not set.
This also allows us to move the various backends device caches to FuBackend as
we now have a suitable ID that is for just the backend to use.
