At the moment plugins are doing this a few different ways; either looping
through the HwIds manually (e.g. flashrom) or setting a custom flag that is
checked in fu_plugin_setup (e.g. uefi-recovery).
Define a standard 'Plugin' HwId quirk to simplify plugins.
Devices may want to support more than one protocol, and for some devices
(e.g. Unifying peripherals stuck in bootloader mode) you might not even be able
to query for the correct protocol anyway.
It is far too easy to forget to set FWUPD_DEVICE_FLAG_NO_GUID_MATCHING for new
plugins, and without it it all works really well *until* a user has two devices
of the same type installed at the same time and then one 'disappears' for hard
to explain reasons. Typically we only need it for replug anyway!
Explicitly opt-in to this rarely-required behaviour, with the default to just
use the physical and logical IDs. Also document the update behavior for each
plugin to explain why the flag is being used.
This allows you to have two identical Unifying plugged in without one of them
being hidden from the user, at the same time allowing a HIDRAW<->USB transition
when going to and from bootloader and runtime modes.
This removes the workaround added in 99eb3f06b6.
Fixes https://github.com/fwupd/fwupd/issues/2915
Only a small amount of the firmware on the LVFS will be available. The user
can use --ipfs on the command line for testing, or change the system-wide
default in /etc/fwupd/daemon.conf.
The IPFS daemon and command line client will need to be installed manually.
The docs for `fwupd_device_get_children()` make it very clear that only the
parent should be assigned. Also add a warning to `fwupd_device_add_child()`
explaining it is for internal daemon use only.
We forgot to include FwupdClientDownloadFlags when adding the original method
fwupd_client_install_release() -- and we want to use additional download flags
for operations in the future.
The metadata might want to pass more than one location URI to the client, for
instance if the file is available from more than one HTTP mirror.
Use the noun of location to match the AppStream <artifact> naming; this is the
last place where LVFS AppStream diverges from the official specification and
it would be good to bring fwupd back into line -- although the LVFS will have
to write both elements for a very long time.
See https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html
Also: we're not changing the format of the `Uri` GVariant key to preserve both
forward and backwards compatibility of the library. We can remove it when we
next break API.
We don't want the (shared) progress notifications going to the thread-default
GMainContext by default as this changes behaviour (ABI?) with older libfwupd
versions.
If the client really does want progress notifications to go to a different
GMainContext they it can call fwupd_client_set_main_context() with the desired
context, e.g. g_main_context_get_thread_default() or g_main_context_new().
This has the intended side effect of returning progress and state notifications
to the main thread, which is typically (but not always) the thread that created
the FwupdClient object.
From Philip's guide: "Never iterate a context created outside the library,
including the global-default or thread-default contexts. Otherwise, GSources
created in the application may be dispatched when the application is not
expecting it, causing re-entrancy problems for the application code."
When using the sync API entrypoints like fwupd_client_get_devices() these call
into fwupd_client_connect() to ensure the proxy is set up. This is not thread
safe and chaos ensues if you call two sync functions from different threads,
like GNOME Software does at startup...
Use a mutex to protect access to this shared resource.
Original test code from Philip Withnall, slightly tweaked by me. Thanks!
The end year is legally and functionally redundant, and more importantly causes
cherry-pick conflicts when trying to maintain old branches. Use git for history.
That giant uint64_t isn't looking so big now, and we'll want to add even more
to it in the future. Split out some private flags that are never useful to the
client, although the #defines will have to remain until we break API again.
This fixes:
DEPRECATION: Library fwupd was passed to the "libraries" keyword argument of
a previous call to generate() method instead of first positional argument.
Adding fwupd to "Requires" field, but this is a deprecated behaviour that
will change in a future version of Meson.
Asking the user for the UID mapping isn't working very well, as it requires lots
of manual handholding. It also doesn't work very well when the device vendor
does not actually have a PCI ID or if the vendor has split into two entities.
Just use the OUI address as an additional VendorID and match any of the device
IDs against any of the metadata-supplied values.
The fprint daemon only keeps the device open for 5 seconds and then releases it,
which seems like a small window to hit.
But! We're asking the user to authenticate with the same device we're about to
upgrade so a different part of the stack woke up the hardware just before we're
about to deploy an update onto it.
Just retry a few times to make sure the device is idle. Use a flag to prevent
accidentally causing regressions in other plugins.
Fixes https://github.com/fwupd/fwupd/issues/2650
For fuzzing we want to exclude libcurl support as it depends on other very heavy
libraries like OpenSSL or libtasn which make the fuzzing binary much larger if
linked statically.
