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 logic error wasn't being caught because the `DelayedActivation`
sysfs code wasn't running.
Basically the WD19TB device will have `skips-restart` applied by the quirk
by default. After `fu_thunderbolt_device_setup_controller` has run
it will have `skips-restart` removed but `usable-during-update` applied
if on a new enough kernel.
In this circumstance the `DelayedActivation` would re-apply `skips-restart`
which is the wrong intended behavior per 834b28009d
The Thunderbolt plugin wasn't actually working properly for
`DelayedActivation` because Thunderbolt devices weren't actually registered.
This only affected ChromeOS.
WD19TB uses skip-restart in some cases, but not all.
The matrix of cases is enumerated in 834b28009d
Unfortunately in the most common case now - new kernel and new daemon
`skip-restart` *isn't* used. The device should be left in a `needs-activation`
state though.
Use this to skip the trigger of failed upload report.
Fixes: #2731
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.
