65e44cac96
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. |
||
|---|---|---|
| .. | ||
| altos | ||
| amt | ||
| colorhug | ||
| csr | ||
| dell | ||
| dfu | ||
| ebitdo | ||
| nitrokey | ||
| raspberrypi | ||
| steelseries | ||
| synapticsmst | ||
| test | ||
| thunderbolt | ||
| thunderbolt-power | ||
| udev | ||
| uefi | ||
| unifying | ||
| upower | ||
| meson.build | ||
| README.md | ||
Adding a new plugin
An extensible architecture allows for providing new plugin types (for reading and writing different firmware) as well as ways quirk their behavior.
You can find more information about the architecture in the developers section of the fwupd website.
If you have a firmware specification and would like to see support in this project, please file an issue and share the spec. Patches are also welcome.
Plugin interaction
Some plugins may be able to influence the behavior of other plugins. This includes things like one plugin turning on a device, or providing missing metadata to another plugin.
The ABI for these interactions is defined in: https://github.com/hughsie/fwupd/blob/master/src/fu-device-metadata.h
All interactions between plugins should have the interface defined in that file.