This means we do not do the GUID or counterpart GUID matching when adding
devices. Only an exact device-id match or when both the physical and logical
IDs match will the device be considered the 'same'.
This is to handle devices that could share the same GUIDs in both child and
parent modes where the logical ID differs.
Cached metadata was not working for setting the supported flag because
of a difference in version format. The version format needs to be applied
to the device before applying the supported flag.
This particularly helps UEFI devices which set the version format to number
but in practice all metadata sets it to something different.
Fixes: #2005
The idea here is that the device would not come back after it was restarted,
and skipping the attach in the engine was only working around the fact that the
ebitdo did not split out an ->attach() function.
We can't really blame it; we only decoupled the _IS_BOOTLOADER requirement
for ->attach() recently...
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.
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.
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.
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.
This fixes the confusing case where installing the CCGX firmware on a dock
would reboot the hub, leading to this output:
Installing on USB-I2C Bridge… ]
Installing on USB2.0 Hub…[************************************** ]
Installing on USB3.1 Hub…[************************************** ]
Installing on USB2.0 Hub…[************************************** ]
Installing on USB3.1 Hub…[************************************** ]
Installing on ThinkPad USB-C Dock Gen2 USB Audio…*************** ]
Installing on USB-I2C Bridge…*********************************** ]
Restarting device… [***************************************]
With the patch, this is now:
Installing on USB-I2C Bridge… ]
Restarting device… [***************************************]
Rather than return the first device with a matching counterpart GUID, and then
check to see if it was removed -- instead just return any item that matches and
has been removed.
This fixes updating the Logitech unifying receiver when more than one type of
device (e.g. RQR12 and RQR24) are connected.
Switch to downloading the signature first, which we can then load to get the
suffixed build-specific URL of the actual metadata file. You need to have
libjcat 0.1.1 installed and fwupd built against the new version for this to
work.
Fixes https://github.com/fwupd/fwupd/issues/391
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
parent ID 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.
This fixes the common problem encountered when developing plugins:
./src/fwupdmgr get-devices
Unsupported daemon version 1.4.0, client version is 1.4.0-179-gcf8095d5
A Jcat file can be used to store GPG, PKCS-7 and SHA-256 checksums for multiple
files. This allows us to sign a firmware or metadata multiple times (perhaps
by the OEM and also then the LVFS) which further decentralizes the trust model
of the LVFS.
The Jcat format was chosen as the Microsoft catalog format is nonfree and not
documented. We also don't want to modify an existing .cat file created from WU
as this may make it unsuitable to use on Windows.
More information can be found here: https://github.com/hughsie/libjcat
Use only one GMainLoop in FuDeviceList; we can only iterate one loop at a time
anyway, and having the mainloops per-item complicates the lifecycle of the
fu_device_list_wait_for_replug() functionality considerably.
If the device has a child with a longer remove_delay we actually crash because
the FuDeviceList tries to remove the child device twice. Just remove all the
children when the parent remove delay elapsed rather than set up each device
with a unique timeout.
