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.
Always set the AppStream app properties on the FwupdRelease. In some cases we
were returning FwupdRelease objects with no name or summary which gnome-software
was ignoring.
Kernel v4.15 added support for native enumeration of Thunderbolt
topology. The enumeration mode affects both the BIOS and TBT FW
operation so they must agree on it. Platforms may support both modes,
native and "legacy" (or "BIOS-assist").
This change makes sure the new image is compatible with the current
controller mode (otherwise the BIOS and TBT FW will not be alligned on
it at least until next boot) and also adds a new GUID generation logic
for a controller in "native" mode so LVFS could contain 2 images, one for
the "legacy" mode and one for "native".
Signed-off-by: Yehezkel Bernat <yehezkel.bernat@intel.com>
The SF30/SN30 pro support 4 different modes:
* Switch mode (START + Y)
This looks like a nintendo switch pro controller
* Xinput mode (START + X)
This looks like an XBOX 360 controller
* Dinput mode (START + B)
This looks like a more generic gamepad
* macOS mode (START + A)
This looks like a Sony DS4 controller
3 modes have had a difficult time enumerating in fwupd.
Switch mode:
* failed to add USB device: unexpected device response
Xinput mode:
* failed to add USB device: USB error on device 045e:028e : Pipe error [-9]
macOS mode:
* failed to add USB device: failed to send to device on ep 0x01: USB error on device 054c:05c4 : Input/output error [-1]
The only mode I've gotten a nearly full update flow working is Dinput
so far. After updating the controller comes back in switch mode.
Using old versions of gcab we could only do one thing: extract the files in the
cabinet archive to a new directory in /tmp, and then fwupd would have to read
them back in to memory to parse them. This was both inelegant and wasteful, and
probably not an awesome idea from a security or privacy point of view.
Using libgcab >= 1.0 we can decompress to a GBytes blob, and then verify the
firmware and metainfo file without anything being written to disk.
As this is a security sensitive operation, move the fwupd-specific helper code
out of libappstream-glib and also add a lot of internal self tests.
The gcab code will have to remain in libappstream-glib for a long time, but we
don't have to use it. Handling the cab file here also allows us to fix two
long-standing bugs:
* MetaInfo or firmware files in a subdirectory are handled correctly
* The archive can also be self-signed using PKCS7 instead of using GPG
In the case of multiple <component> sections with different AppStream IDs, but
with the same GUID <provides>, filter using the requirements rather than just
choosing the first one.
This allows the update of Logitech devices with secure bootloaders. Many thanks
to Ogier Bouvier for identifying the problem.
This means we can trivially support new devices in the future without compiling
any new code. This makes it easier to add support for new hardware for LTS
distros like RHEL.
This ensures we get progress events when replugging a device. Also, remove the
callbacks on the 'old' device to avoid causing multiple events on a 2nd-replug.
CSR is short for Cambridge Silicon Radio, which is a the OEM that makes most
of the bluetooth audio chips in vendor hardware. The hardware vendor can enable
or disable features on the CSR microcontroller depending on licensing options.
The hardware vendor can also use a custom USB descriptor, or just set a custom
PID. In the latter case we need to set the vendor and model to reality using
quirks.
This commit allows the user to update the firmware in the AIAIAI H05 wireless
headphones.
