As a consequence, the version number is also set in the event that the silicon
or firmware app-id is not set, which also seems like the right thing to do.
The idea here is that the device would not come back after it was restarted,
and skipping the attach in the engine was only working around the fact that the
ebitdo did not split out an ->attach() function.
We can't really blame it; we only decoupled the _IS_BOOTLOADER requirement
for ->attach() recently...
The USB 2.0 controller is used as a 'backup' in case the USB 3.0 firmware fails
to start. Set USB 3 hubs as a greater priority so that the USB 2 ones do not
not get added if the USB 3 firmware is working.
Some plugins are just simple wrappers around custom GType creators and which
specific plugin created is not a good way to make a policy decision.
If this was added to work around a bug, we need to find a better solution or
fix the root cause.
Instead of using RequiresMountsFor=/snap/fwupd/current, which will not
work since /snap/fwupd/current is a symlink [1].
This will work since the mount units generated by snapd all have
Before=snapd.service, so will be stopped after snapd.service during
shutdown.
With After=snapd.service, fwupd-activate.service will then stop before
snapd.service, at a point when all snap mount units are still running.
Fixes the issue where fwupd-activate.service hangs when stopped, causing
a stop job timeout during shutdown.
[1] See https://github.com/systemd/systemd/issues/8907Closes#1654
If we do not ->open() the device (e.g. because it uses a parent device to proxy
writes) then the child never gets a DeviceID which causes all kinds of issues.
Getting the version string from git means the commit version changes each time
we commit any patch, which means we need to use --force to install firmware
when building fwupd against a version that should be compatible.
It is also very inconvenient not bumping the release version for git snapshots
as firmware can no longer depend on the "planned" release triplet.
tl;dr: A good idea for Flashrom, not so awesome for me.
The m-stack DFU quirk also requires that we get the runtime status so that the
USB_DFU_SUCCESS_FUNC callback gets called. We were doing this by accident
before, and since switching to the FuDevice subclass this was dropped.
The dfu_device_refresh_and_clear() function is safe to call on a device which
does not have a working runtime interface.
These are a regression of 9e755e2a5 when devices are asleep.
However due to the current kernel and daemon architecture, logitech devices
are not checked again at any time so if the device isn't awake when
fwupd is started or the unifying dongle is plugged in it won't be present.
This will be changed in the future when the kernel has change events
associated with devices waking up.
Fixes: #1973
