If we update fwupd 'live' rather than from an ostree or offline update then
kill the running instance unless a firmware update is ongoing.
When users update fwupd at runtime they often forget to restart the fwupd daemon
and say that the update didn't fix it when actually they using the the old code.
This is intended for devices that it is not safe to immediately activate
the firmware. It may be called at a more convenient time instead.
Both fwupdmgr and fwupdtool support the feature.
- if called at runtime with fwupdmgr it uses the daemon
- during shutdown fwupdtool uses the pending.db to perform this feature.
Plugins are allowed to 'opt-out' of this behaviour using _RULE_INHIBITS_IDLE.
This should be used where waking up the hardware to coldplug is expensive,
either from a power consumption point of view, or if other artifacts are going
to be seem -- for instance if the screen flickers when probing display devices.
This functionality is also inhibited when the actual upgrade is happening,
for obvious reasons.
Admins can turn off this auto-sleep behaviour by editing the daemon.conf file.
Fixes https://github.com/hughsie/fwupd/issues/417
The libxmlb library is much faster to query, and does not require the daemon
to parse the XML metadata at startup. It's a zero-copy mmap design that is more
modern and less clunky.
RSS has reduced from 3Mb (peak 3.61Mb) to 1Mb (peak 1.07Mb) and the startup
time has gone from 280ms to 250ms.
This allows a frontend to call update on an individual device ID which will
cause a CAB file to be downloaded, but then also re-use the same CAB file to
try to process devices with a relationship as part of a transaction.
The profiling data is of limited use, and better data can be obtained using
kcachegrind and massif. Additionally, the profile samples were the cause of the
small RSS growth over time, when in reality the data would only be shown when
the verbose switch is used at daemon startup.
Now devices can have multiple GUIDs and do not share platform IDs there is
really no point waiting to add the device.
This allows us to remove a whole lot of code for this now-unused functionality.
Now we can update multiple devices (in multiple plugins) using one firmware
archive we need a way to cleanup after all the plugins have been run.
Fixes https://github.com/hughsie/fwupd/issues/561
When using failed to open firmware.cab we pass in a device ID of '*' which
tells the daemon to update anything that matches. The current implementation
will fail in two ways:
* If duplicate hardware is installed (for instance two Unifying receivers) then
only the first matching device will be updated.
* If the firmware archive contains two different images then we only try and
upgrade the first device that matches. This means we're unable to update
composite devices using one firmware file.
To fix both issues, carefully build a list of tasks that can be processed using
the given firmware and installed devices, request authentication using all the
different action IDs, then upgrade all the devices one-at-a-time.
Based on a patch by Mario Limonciello <mario.limonciello@dell.com>, many thanks.
GLib creates two static inline functions for paramaters that may
not be used that set off warnings in clang but not gcc.
Ignore these on clang builds everywhere that
G_DEFINE_AUTOPTR_CLEANUP_FUNC is used.
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.
