These are GUIDs that are related to the main device, but should not be used for
quirk matching. For instance, we might want to list the GUIDs for a bootloader
mode, but we don't want to import all the quirks for the bootloader when in the
runtime mode.
This pivots the data storage so that the group is used as the preconditon
and the key name is used as the parameter to change. This allows a more natural
data flow, where a new device needs one new group and a few few keys, rather
than multiple groups, each with one key.
This also allows us to remove the key globbing when matching the version format
which is often a source of confusion.
Whilst changing all the quirk files, change the key prefixes to be more familiar
to Windows users (e.g. Hwid -> Smbios, and FuUsbDevice -> DeviceInstanceId)
who have to use the same IDs in Windows Update.
This also allows us to pre-match the desired plugin, rather than calling the
probe() function on each plugin.
We need to remove the flag if the quirk is not present.
Fixes the cosmetic-but-scary-looking 'failed to send to device on ep 0x01: USB
error on device 2dc8:9001 : Input/output error'.
Fixes the other half of https://github.com/hughsie/fwupd/issues/565
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.
This makes more sense; we're updating the device, not the plugin itself.
This also means we don't need to funnel everything through callbacks like
GFileProgressCallback and we can also update the state without adding an
explicit callback to each derived device type.
It's actually less scary to see a SHA1 hash than it is to see a path like
/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.2. It's also way easier to
copy and paste into the various fwupdmgr command that require a device ID and
also means we can match a partial prefix much like git allows.
If we also move to a model where plugins can be changed during different stages
of the update (e.g. during detach) then the device might change connection type
and then the sysfs path not only becomes difficult to paste, but incorrect.
Session software doesn't care about the format of the device ID (it is supposed
to be an implementation detail) and so there's no API or ABI break here. A few
plugins also needed to be ported, but nothing too worrying.
This allows end-users testing a specific plugin to start fwupd with an extra
command line parameter, e.g. `--plugin-verbose=unifying` to output a lot of
debugging information to the console for that specific plugin.
This replaces a lot of ad-hoc environment variables with different naming
conventions.
This is a large commit that removes all the providers and turns them into
plugins. I think having both providers _and_ plugins was super confusing.
Plugins are loaded at runtime so you could in theory develop a new plugin
without putting it in the fwupd source tree, although there are no installed
headers or PC files as I'm not sure it's a good idea at this stage.
This commit moves all the per-provider docs, tests, notes, debug dumps and test
data to plugin-specific directories -- these also allows the plugin author to
"own" more of the source tree so we don't enforce fu- prefixes and the style
guide everywhere.
This allows us to run the same action on all the plugins in the future, so we
could have a prepare(FuPlugin, FuDevice) and cleanup(FuPlugin, FuDevice) run
on *all* plugins, so doing an update using one plugin would allow us to work
around hardware quirks in other plugins.
If I've broken your out-of-tree provider it's trivial to port to the new API
with sed and a fixed up build file. If you need help please let me know.
