The work for this landed in what will turn into efivar 33.
Later down the road when efivar 33 is in most the major distros
this can be removed and a requirement set for efivar 33.
This shares your history with a reporting server, typically the LVFS.
NOTE: no data is sent without the user opting-in, and the data sent is shown to
the user before upload.
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
