Some (HIDPPv1?) devices don't like being probed, and in some cases actually
stop working altogether. As we only really support the K780, just whitelist
that and another test device.
Fixes bugs like #127 and #258
By removing the device from the hash table before we add it to the devices
array we could inadvertently drop the last object reference if the plugin is
not using the (optional) cache.
Just re-arrange things to fix https://github.com/hughsie/fwupd/issues/259
Specifically, fix the progressbar to:
* Print at 100% after an 'unknown' percentage task has completed
* Refresh the progressbar if being called without a main loop running
* Allow the progressbar to start with a h-offset without moving 'left'
* Don't cause high CPU load when calling fu_progressbar_update() ever few us
Also, add some unit tests to discover all the issues.
It only remained on FwupdResult because I couldn't make up my mind about whether
it was a property of the device, or the firmware release. It's more logically
the latter, as you could have a .cab file with multiple versions of the
firmware and only the first being signed.
UEFI updates don't need to be retried since a785a1c. If the call to Install()
failed with NOT_SUPPORTED we can just show the error rather than doing the
little dance and involving the offline pending database for no reason.
Fixes some of https://github.com/hughsie/fwupd/issues/255
For a few months the lvfs-testing remote has not included firmware already
present in the stable lvfs remote. This means if you enable the testing remote
then components in the stable remote are not available to fwupd.
Instead of a simplistic check on the component ID, add the missing releases
no matter the ordering of the remotes.
This was only ever added for gnome-software, and is too inflexible for anything
else. It turns out we don't even need it in GNOME, as we can construct a
suitable ID ourselves using the existing values.
It was also ambiguous whether the unique ID was in reference to the device
or release -- and for gnome-software we need both.
It only remained on FwupdResult because I couldn't make up my mind about whether
it was a property of the device, or the firmware release. It's more logically
the former, and that's how plugins are using it.
