```
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.
Some firmwares only update one part of the system, e.g. the EC or ME firmware.
Other updates include all the updates needed for the whole system, and vendors
have been doing different things with the component name due to this.
To fix, add an enumerated set of firmware 'categories' that can be set by the
uploader in the metainfo.xml file (or changed the LVFS) which automatically
set the name suffix.
Only append the translated version in the client when <categories> has
not been set, as the LVFS is still operating in compatibility mode and setting
the <name> with the prefix. Add the support to fwupd now so we can switch in
about 9 months time.
This stops us scheduling an update that has FWUPD_DEVICE_FLAG_REQUIRE_AC when
on battery power, as we don't show messages when in the offline updates mode.
Of course, we still check for AC when we reboot, but the common case is where
we reboot into the offline mode just after we schedule the update without
changing the hardware configuration.
