Unloading the GModule means that any GTypes registered by that plugin cannot be
queried.
Other plugins could unintentionally call methods like G_OBJECT_TYPE_NAME()
which makes the daemon explode. There's no need to actually close the module,
and so we're just making life diffult for ourselves for no good reason.
Fixes the other half of https://github.com/fwupd/fwupd/issues/3156
This can be used like this:
fwupdtool firmware-sign firmware.cab rhughes_signed.pem rhughes.key
Test signing certificates can be generated using the example script here:
https://github.com/hughsie/libjcat/blob/master/contrib/build-certs.py although
these certificates should not be used for enterprise use.
This function returns a list of sibling devices that have a chosen subsystem,
allowing callers to perform a limited walk of the device tree to locate related
devices.
This allows plugins to set the battery power state of the *machine* which means
we can automatically inhibit devices with FWUPD_DEVICE_FLAG_REQUIRE_AC set.
It also allows to set the BatteryThreshold to 25% for Lenovo hardware, and we
can override other vendors with further quirks as required.
Fixes https://github.com/fwupd/fwupd/issues/3084
The activation flag is stored into the history database, but not all
plugins will want to inherit it on coldplug the next time the daemon
is started.
For example the Dell Dock plugin will query this information from the
device and it will prevent getting into a bad state as a result.
Fixes: #3106
If only one plugin is enabled and there exists a device match for a GType that
has not been registered then the user sees a GType error about not being able
to create a device that wouldn't be created anyway.
By removing the error in the quirk parser we will catch actual errors in
fu_plugin_runner_backend_device_added() which actually does chcek for
FWUPD_PLUGIN_FLAG_DISABLED.
Fixes https://github.com/fwupd/fwupd/issues/3099
There is a lot of code in fwupd that just assigns a shared object type to
a FuPlugin, and then for each device on that plugin assigns that same shared
object to each FuDevice.
Rather than proxy several kinds of information stores over two different levels
of abstraction create a 'context' which contains the shared *system* state
between the daemon, the plugins and the daemon.
This will allow us to hold other per-machine state in the future, for instance
the system battery level or AC state.
We already have two things managing the UPDATABLE_HIDDEN->UPDATABLE transition,
and we're about to add a third.
Add a 'stackable' inhibit-style API so we do not accidentally mark a device as
updatable when it should remain hidden.
