This fixes a regression introduced by 2031ce3bf6
that leads to:
```
USB error on device 2dc8:5750 : No such device (it may have been disconnected) [-4]
```
The root of this problem is that we were trying to use pending.db as both a
pending report store and also a record of history, so you could see updates for
device foo 1.2.3->1.2.4 and then 1.2.4->1.2.5.
This sort-of half worked, but it meant in some cases we matched on the old
device version, sometimes on the new release version and sometimes matching on
either.
The problem was that in various places we were using the device ID as *the*
primary key, and so we had various functions like fu_history_get_device_by_id()
that expected to return just one device, not several.
The device ID also changes if the device is moved from USB plug to another, and
so it got even more complicated again trying to de-dupe the devices.
The sanest thing to do is to decide that pending.db only contains the latest
attempt to go from one version to another using device-id as the primary key.
This makes reporting work reliably now, although has the effect you can't
report a 1.2.3->1.2.4 and 1.2.4->1.2.5 at the same time. Note, if you tried to
do the latter before, the update-error (if set) would be wrong on the second
report...
For the 1.3.3 release make it all simpler and so the reporting works reliably.
Longer term we can design a better database schema that uses unique ID to
represent the *transaction* itself, that isn't tied to the device ID in any way.
This might mean extending the DBus API to cope with multiple devices being
returned with the same device-id set.
It's not usual to open the device from inside the device, otherwise there is a
possibility of a deadlock. For devices without the ->prepare() virtual function
the ->open() should either be a NOP or very fast indeed.
To debug flashing failures it's sometimes requried to get a SPI dump of the
hardware to analysis.
Add a debug-only command that lets us dump the device from the engine.
During startup we do 1898 persistent allocations to load the quirk files, which
equates to ~90kb of RSS. Use libxmlb to create a mmap'able store we can query
with XPath queries at runtime.
This makes the daemon less destructive at startup, especially if the ESP
is not mounted.
It's stored in 3 different places right now, so move it into one point of truth.
Now the ESP is detected when needed including all point of time safety checks and
dynamically mounted and unmounted if necessary.
As the plugin is allowed to change print out the entire FuDevice before
performing each step when in verbose mode.
Note, these are only show during update if run with --verbose, not at startup.
```
Uploading firmware reports helps hardware vendors to quickly identify failing and successful updates on real devices.
Upload report now? (Requires internet connection):
0. Do not upload reports at this time, but prompt again for future updates
1. Do not upload reports, and never ask to upload reports for future updates
2. Upload reports just this one time, but prompt again for future updates
3. Upload reports this time and automatically upload reports after completing future updates
1
key ReportUri not supported
```
Somewhat embarrassingly we were not actually showing the 8bitdo manual detach
images because... we were not actually exporting them. I don't know how this
ever worked in GNOME Software, but it would also explain the low 'success' rate
of the 8bitdo firmware on the LVFS.
This will also be used by Logitech in the future for the C1 Unifying devices.
To work in gnome-softare, this also needs the matching functionality to call
gs_app_add_screenshot() with the new exported data.
We don't need to enumerate USB and UDev devices in the self tests. In the case
where the probe fails (due to a permissions error, as not running as root) we
don't want the tests to fail.
When the LVFS switches over to outputting <issues> rather than appending to the
update description we need to be in a position to display the new data.
This allows plugins to rescan hardware based on uevents of any device class
registered with fu_plugin_add_udev_subsystem().
Additionally, the events are rate limited to avoid causing lots of extra plugin
processing when replugging hardware.
Users are getting confused when they're being told that AC power is required
when they are already on AC power... but the battery is too low to perform the
update.
This leads to madness, as some formats are supersets of the detected types,
e.g. 'intel-me' is detected as 'quad' and 'bcd' is detected as 'pair'.
Where the version format is defined in a specification or hardcoded in the
source use a hardcoded enum value, otherwise use a quirk override.
Additionally, warn if the version does not match the defined version format
Set `UpdateError` in this case, and prevent updates.
If the `VersionFormat` is not known, then the device will later have
problems installing firmware with errors like:
```
failed to get release version: version format unset and version 13000001 ambiguous
```
or
```
Firmware version formats were different, device was '(null)' and release is 'plain'
```
This generally should be corrected by quirking the device.
I'm getting a bit fed up with failed reports from arch users where they just
have a broken system. I don't think it's useful to upload to the LVFS or notify
the vendor about failures like this.
This allows several things, for instance:
* Adding or removing blacklisted plugins or devices
* Changing the idle timeout where allowed
...without a user needing to manually modify a configuration file.
This is arguably the more correct fix, regardless of the UEFI quirk use as each
release was reading and converting the exact same property from the component.
Fixes https://github.com/hughsie/fwupd/issues/1156
This allows us to print the daemon-specific properties like VersionFormat when
debugging. The caller can continue to operate on the subclassed FwupdDevice
without changes.
