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.
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
This was incorrect when were were adding child devices by GUID (as we should
have been setting the transaction *order*, not the plugin *priority*) and just
completely unused now we're using the ParentGuid to set the parent and not
adding a reference to the child.
This also means we do the right thing when plugins call fu_device_add_flag()
directly, instead of just from a quirk file.
For instance, now `Flags = ~updatable` is a valid and useful thing to have and
allows us to remove the `Flags = None` hack.
```
ok 10 /fwupd/client{remotes} # SKIP no valid daemon: Error calling StartServiceByName for org.freedesktop.fwupd: Failed to activate service 'org.freedesktop.fwupd': timed out (service_start_timeout=25000ms)
ok 11 /fwupd/client{devices} # SKIP no valid daemon: Error calling StartServiceByName for org.freedesktop.fwupd: Failed to activate service 'org.freedesktop.fwupd': timed out (service_start_timeout=25000ms)
```
We use the ParentGuid quirk key to logically 'tie-together' different discrete
devices into one logical device, for instance making the USB soundcard in a hub
the child of the USB controller on the same PCB.
Setting the discrete child is sometimes correct, for instance when rebooting
the hub, the audio device also goes away -- but it's also sometimes wrong.
If we set the child for a discrete device and the parent does *not* go away
then we get to a situation where the child reference may no longer be valid
if it comes back as a different object.
When we try to remove this no-longer-valid device with the removal timeout the
daemon segfaults. This is realy bad.
Continue to allow using fu_device_add_child() in plugins, where we know the
child lifecycle is is matched by the the parent. In the engine just set the
weak parent directly and let the client use this information to show the tree
of logical devices correctly. There's no benefit to setting up the children as
referenced objects anyway.
We add the child devices using fu_plugin_device_add() so we have to remove them
the same way. The original fix is wrong, as it leaves child devices when the
parent is removed.
This reverts commit 02b588c035.
This is nice in theory, until you need to look at the bootloader status of the
parent, or of a different device entirely. Handle this in plugins for the few
cases we care about and stop setting or clearing IS_BOOTLOADER manually just to
get the vfuncs to be run.
Note: I do not think we want to use cleanup() for attaching devices not in
bootloader states -- as cleanup is only run at the end of the composite update.
In this case, a plugin was doing:
g_autoptr(FuDevice) parent = fu_device_get_parent (device);
Which is not valid as it is `(transfer none)` but that shouldn't be enough to
get the daemon to crash. If the FuDevice refcount drops to zero just print
a critical warning with the pointer (no FuDevice details are available) and
remove the FuDeviceItem from the device list.
Using `G_DEBUG=fatal-criticals` it is very easy to backtrace at the right place
and find out which naughty plugin needs to go on the thinking spot.
Doing this unconditionally means we accidentally 'bleed' one device mode into
another in a non-obvious way. For instance, a device might have two operating
modes with different GUIDs. If firmware is supplied for both modes in the same
cabinet archive then we might accidentally match the 'wrong' firmware when
the daemon has observed a mode switch and added the counterpart GUIDs.
We only really need the counterpart GUIDs when switching between Jabra, 8bitdo
and DFU devices where the DFU bootloader VID:PID is not manually tagged with
`CounterpartGuid` in a quirk file. In the general case lets keep it simple to
avoid difficult to find bugs.
