Previous to having the history database we could only notify about firmware that
as installed using the uefi plugin, as that had a few system-wide API calls to
say 'this update failed' or 'this was the error'.
Now we have the local history database not only can we report more details about
the UEFI update (e.g. the old version number) but we can also offer the same
functionality for all other plugins.
Although this does rework how the data for GetResults() is populated, it does
make the FuEngine object quite a lot less confused.
It also fixes a warning in the fwupd plugin for gnome-software, which was
expecting the FwupdRelease to be populated for the FwupdDevice.
4a036018 broke the callback progress by putting the wrong device type in.
23:34:11:0715 GLib-GObject invalid cast from 'SynapticsMSTDevice' to 'FuDevice'
23:34:11:0715 Fu fu_device_set_progress: assertion 'FU_IS_DEVICE (device)' failed
b6f79556 caused the device ID strings to change, which synaptics
MST plugin was relying upon.
Update to use metadata instead to communicate this information.
This does mean fixing up the version numbers. The idea is that we have a
virtual device that goes from 1.2.2->1.2.3 for an update, and 1.2.3->1.2.2 for
a downgrade.
In newer releases libusb has started returning LIBUSB_TRANSFER_ERROR (rather
than the arguably more correct LIBUSB_TRANSFER_STALL...) when the device is
removed before the control transfer has completed.
This will be useful in the future for debugging crashes with known
problematic versions of libsmbios.
Also use this information to turn off the blacklist from previously
bad known combinations of libsmbios + certain systems
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.
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.
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.
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.
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.
Switching to build in -werror in 4016c839a8
was not working properly. Adjust the CI builds to use --werror instead.
Also while doing this, enable -werror in clang builds.
