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().
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
```
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.
This allows us to match non-DeviceID GUIDs, and also GUIDs we don't know how to
generate.
To make this fully useful, search for device quirks when GUIDs are added.
In this instance, we define the 'same device' to be a FuDevice that has at
least one matching GUID. We allow the plugins to define which one is 'better'
than other plugins, and use this to only have one FuDevice for the physical
device.
Alternative to https://github.com/hughsie/fwupd/pull/604
If the daemon either de-duplicates or replaces the object passed emitted from
device-added then the object set as the alternate may not be the same instance
as the daemon version. This causes weird things to happen.
To make this less fragile, specify the *ID* of the object that should be the
alternate device, which allows the daemon to do clever things, and then assign
the object from the ID as the last step.
Although fixing no bug, this makes implementing future functionality easier.
Using just the default GUID is fragile and might break if the GUIDs get added
in the 'wrong' order or if the GUID list is sorted.
Fixes https://github.com/hughsie/fwupd/issues/518
This allows us to find out the logical parent device, for instance in composite
devices with more than one firmware image for a single device.
We also allow lazily specifying the device parent using a GUID and the engine
then automatically sets the parent object when the GUIDs match, which allows
children and parents to exist in different plugins.
If we plug in USB device A, remove it, plug in USB device B and get the same
autogenerated string all kinds of nasty things happen to the history database.
Rename FuPending to FuHistory to better represent what the object is now doing.
Also, while we're here, switch to using SQLite prepared statements to avoid a
possible invalid read on i386 hardware.
This makes more sense; we're updating the device, not the plugin itself.
This also means we don't need to funnel everything through callbacks like
GFileProgressCallback and we can also update the state without adding an
explicit callback to each derived device type.
