The name, summary and icon are not strictly required for a USB device
supporting both DFU interfaces, but having this extra data makes GNOME Software
look much nicer. Using the quirks feature means we can merge in support for new
devices after fwupd has been released for stable distros.
`Not compatible with fwupd version 1.0.2, requires >= 1.0.3`
...is easier to understand than...
`Value of org.freedesktop.fwupd incorrect: failed predicate [1.0.3 ge 1.0.2]`
This saves all the USB plugins from connecting to the context and managing the
device lifecycle and allows devices that uses FuUsbDevice to be removed
automatically.
This makes supported plugins *much* smaller indeed.
By filtering out the devices not in runtime we have two problems:
* We can't use fwupdmgr to 'fix' any devices that failed to flash and are
stuck in bootloader mode
* We can't transition from a runtime-less FuDevice to a DFU-capable FuDevice.
This allows the Nitrokey to be updated using fwupd.
When changing from runtime->bootloader->runtime the usual way of handling this
in a fwupd plugin is to:
* reset the device and wait for a replug
* flash the hardware
* reset the device and wait for a replug
This works well when the runtime and bootloader modes are handled by the same
plugin. For situations like the Nitrokey device, where one plugin handles the
runtime (nitrokey), and another handles the bootloader (dfu) we have to have
the ability to 'ignore' the device removal and just issue a 'changed' signal
so the client refreshes the properties.
In the case where we can trigger the replug automatically we can have to wait
for a USB re-enumeration (typically a few hundred ms) but when the user is
requred to unplug, and then replug we have to wait a bit longer.
The 'remove delay' allows us to modify per-device the removal delay. In the
case the device does not show back up in the correct time the device will be
auto-removed and the session will get a DeviceRemoved signal. In the case where
the device in bootloader mode shows up within the timeout the session just gets
a DeviceChanged event.
For the duration of the delayed removal the flags for the device are set to
zero to ensure the session does not try to interact with the device whilst
re-enumerating.
This moves more functionality out of the engine, and will allow us to add some
cleverness to the device list to allow the FuDevice to be shared between
different plugins.
The ColorHug plugin was the very first plugin for fwupd, and it's not been
ported to use all the various helpers used in other USB plugins. It shows.
This gets rid of a lot of complexity and makes the plugin more reliable.
Kernel 4.15 adds support for Thunderbolt P2P devices via
CONFIG_THUNDERBOLT_NET. When turned on and activated fwupd will
show an empty device representing the IP connection between machines.
These device types aren't useful in fwupd and should be filtered.
Suggested-by: Mika Westerberg <mika.westerberg@intel.com>
Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
Although we don't quite do the right thing, we only need to typically work out
the start offset of the firmware. This fixes 'dfu-tool dump foo.hex' for files
produced for the ATMEL ATXMEGA architechure.
Previously, the various install paths were obtained using get_option
as needed.
This patch unifies the directory selection inside the top-level meson
file as requested in https://github.com/hughsie/colord/pull/62.
This allows us to flash hardware like the Retrode and other devices using chips
like the AT90USB1287.
The test files can be re-generated using the sample code found here:
https://github.com/hughsie/fwupd-test-firmware and are designed
to be used on the AT90USBKEY2 development board.
