Rather then always assuming open() fails because of permission denied,
generate the GError code from the errno and add the related strerror to
the message. And ofcourse output the error message in debugging rather
then just ignoring it.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
If recoldplug is called in the middle of a Thunderbolt firmware update it will
cause the Thunderbolt controller to be in the wrong state and make it appear
that the controller update failed.
The type of Dell dock gets used in the device GUID, so make that
mandatory for device enumeration to succeed. Only relying on the
synapticsmst plugin to be cold plugged after the dell plugin isn't
enough to ensure this.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
When hitting a failure during enumerating make sure remote control mode
is disabled again.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
On Dell dock devices set the FU_DEVICE_METADATA_DELL_DOCK_TYPE metadata
field which gets used by the synapticsmst plugin for recognizing dell
dock types.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
A race condition is hypothesized in the following scenario:
1. User starts up the system and fwupd doesn't start automatically.
2. User manually calls fwupdmgr install blah.cab (or fwupdmgr update really) which uses dbus activation to start fwupd systemd unit.
3. This runs coldplug on thunderbolt plugin, no devices found. Thunderbolt power runs coldplug routine.
a. This sets forcepower with a timeout to turn off after 20 seconds.
b. Coldplug exits.
4. update routine starts
a. Thunderbolt plugin starts flash routine.
b. Thunderbolt power plugin turns off force power in middle of flash routine.
c. Issue described happens.
Some devices like the Nitrokey use a generic DFU bootloader that reports a
version number unrelated to the version number of the runtime. Add a flag so
that we can set the correct version when switching plugins during detach and
attach.
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.
