This allows a device to identify with different streams, for instance a Lenovo
laptop could have a coreboot firmware or a AMI firmware. The GUIDs would be the
same, but switching firmware would only be done rarely and very carefully.
Another example would be switching the Broadcom BCM57xx nework adaptors from the
vendor nonfree firmware with a signed PXE image, to the free software reverse
engineered driver with no PXE support (and thus no signed DXE) at all.
It is expected firmware would have additional metadata something like this:
...
<branch>sdcc</branch>
<description>
<p>
This is an alternate firmware built by the community using only free
software tools.
</p>
</description>
<requires>
<id compare="ge" version="1.5.0">org.freedesktop.fwupd</id>
<client>switch-branch</client>
</requires>
...
Additionally, alternate branch firmware will not be returned for clients not
setting the FWUPD_FEATURE_FLAG_SWITCH_BRANCH before the GetReleases request.
The idea here is that we can show the user both a string and an optional
line-art image when the update has completed. The line art is often more well
understood for non-English speakers.
This feature is turned on with the new fwupdtool option `--enable-json-state`
The intended use case is for ChromeOS to be able to save information about
devices on the system when `fwupdtool update` was run to display in the UX at
a later time.
This also allows us to write mixed-endian structures and adds tests. As part of
this commit we've also changed the API of something that's not yet been in any
tarball release, so no pitchforks please.
This makes it much easier to write metainfo files as we don't have to ask OEMs
or ODMs to run fwupdtool or fwupd with --verbose and then sort through hundreds
of debugging statements.
The fwupdmgr get-devices output also now prints output like this:
20EQS64N0C System Firmware
Guid: ddc0ee61-e7f0-4e7d-acc5-c070a398838e
Guid: 40ce5954-bfa8-5762-926b-f4848cb28bc8 <- UEFI\RES_{DDC0EE61-E7F0-4E7D-ACC5-C070A398838E}
We're deliberately not showing the InstanceId lines in the get-updates command
as the instance IDs are not useful in this case. It will also only show the
InstanceID lines when run as a trusted user, for instance root.
The idea is that if the user should know something about the device update
"after" it's succesfully completed then the plugin can set `UpdateMessage`
for the device and a client can show it.
An example would be a device that doesn't reboot on its own and the user
needs to power cycle it manually.
This allows us to find out the logical parent device, for instance in composite
devices with more than one firmware image for a single device.
We also allow lazily specifying the device parent using a GUID and the engine
then automatically sets the parent object when the GUIDs match, which allows
children and parents to exist in different plugins.
It only remained on FwupdResult because I couldn't make up my mind about whether
it was a property of the device, or the firmware release. It's more logically
the former, and that's how plugins are using it.
This allows us to show the devices in a GUI with a nice icon. Some of the icon
mappings are not perfect and I'll be asking the GNOME designers for some
additions to the icon specification.
Custom vendor icons can also be specified, and /usr/share/fwupd/icons would be
a good place to put them. If vendor icons are used they should show a physical
device with the branding, rather than just the vendor logo.
