If another plugin causes a Synaptics MST device to be removed, it
also needs to be removed from the cache to prevent problems when
the device is re-probed.
1) Switch to daemon provided vfuncs for USB
2) Set quirks so that the plugin only runs when Realtek NIC shows up
3) Rely on the daemon to process all removals by parent tree
Objects deriving from FuUdevDevice() like FuNvmeDevice typically want to do
FuDevice->FuUdevDevice->FuNvmeDevice rather than FuDevice->FuNvmeDevice.
This matches what FuUsbDevice does.
The setup() is the counterpart to probe(), the difference being the former needs
the device open and the latter does not.
This allows objects that derive from FuDevice, and use FuDeviceLocker to use
open() and close() without worrying about the performance implications of
probing the hardware, i.e. open() now simply opens a file or device.
Probe is supposed to be used to check things like the VID and PID, and to
optionally add extra GUIDs to the device. Crucially, it doesn't require open()
to operate, and so it's wrong to reprobe() on calling close().
This caused errors of mismatching devices that didn't have platform
ID's set.
Example:
18:40:24:0555 Fu ignoring device 370e10407b1f04ade798a9f1d3e1fa57c67750c3 [uefi] existing device 088df415cdee883ec89563e41e6d495924250174 [amt] already exists
Fixes: 3a8d5328 ("Allow the device list to take care of waiting for the device replug")
Commit 0f72ef2f88 causes probe to be re-run on FuDevices.
Any devices derived from FuUsbDevice that set the "Name" key will have the
quirks re-evaluated when GUIDs are added again leading to warnings like this:
```
(fwupdtool:8259): Fu-WARNING **: 23:04:43.144: device 970e85c8400ed95ec5c02b86e52a0ca4ce6fc051 overwriting same name value: Dell USB hub
```
ComputerHardwareIds.exe seems to strip any trailing whitespace before building
the UTF-16 string for hashing. If a SMBIOS blob contains strings with trailing
whitespace then until now the 'fwupdmgr hwids' output would show different
HwIds than when running Windows on the same hardware -- which confuses everyone.
Although this may change the HwIds from 1.1.1 to 1.1.2 on some hardware, I'd
argue it's more important to match the Windows Hardware IDs rather than have
a 'similar, but not the same' implementation.
This affects the Lenovo X380 Yoga, although may also affect other machines.
We can't pretend we're accurate to 10m in the precision of the float when we're
doing things like USB re-enumeration which can take several seconds. I believe
users want some indication of 'should I wait or go do something else' rather
than any precise timings.
These are GUIDs that are related to the main device, but should not be used for
quirk matching. For instance, we might want to list the GUIDs for a bootloader
mode, but we don't want to import all the quirks for the bootloader when in the
runtime mode.
Rather than guessing the keys that might be present, and doing two hash lookups
for each, get the key values in one call. This is somewhat more performant, and
allows us to do clever things in the future.
At the moment quirks are hashed with a key based on the group appended with the
key, which is sometimes made into a GUID. This is suboptimal as when a device
has many different quirk keys (e.g. Name, Summary and Flags) as we hash and
store the same key prefix each time.
Instead, use a 1st level hash to map the group (typically the GUID) to another
hash table. Then use the 2nd level hash to get the value using the key.
This does increase the query time slightly, although reduces RSS considerably --
although not by as much as you'd think as creating a GHashTable with one entry
is more RSS than just storing the string.
This representation does have one huge benefit: You can now get all the keys
of quirk entry without having to guess what they might be. This lets us do some
more efficiency gains with follow up patches.
Similar to commit 7d35278 regarding the install option with a daemon compiled without
GPG, but now, if you also have a daemon compiled without GPG, and if you have downloaded a
CAB file from LVFS and ran get-details, it would fail to display the contents
of the associated CAB file.
This allows it to still display the contents of the CAB file, and
a warning will be displayed in the logs.
This flag is intended for devices that the restart procedure will
be performed as part of a transactional update by an external
controller.
None of the currently supported devices need this flag.
