Allow a plugins to cherry-pick specific HWIDs and add them as InstanceIds.
By adding them as InstanceIds rather than adding them as GUIDs, the
original string can be found in the output generated by:
$ fupdmgr get-devices
Example output:
Guid: 230c8b18-8d9b-53ec-838b-6cfc0383493a <- main-system-firmware
Guid: de6fd40f-4ec9-5c0b-95e1-8fb13d1b030c <- LENOVO&ThinkPad T410&2537VG5
Guid: 978b0d18-bfe9-5279-9a9f-68dc247a705f <- LENOVO&ThinkPad T410&LENOVO&2537VG5
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
All of these messages continually output are just noise for unsupported
devices:
```
18:11:52:0851 FuPlugin using generic udev_device_added() on optionrom
18:11:52:0851 FuEngine optionrom ignoring: no FWUPD_GUID property
```
The fwupd UEFI plugin refuses to start if bit 3 of the "BIOS Characteristics
Extension Byte 2" (13h) is cleared. Bit 3 is UEFI Specification is supported.
Also, double-check that /sys/firmware/efi does not exist before disabling the
plugin as other machines may be affected too. The quirk then acts to supress
the console warning about the broken SMBIOS value.
Fixes https://github.com/fwupd/fwupd/issues/1342
This allows plugins to rescan hardware based on uevents of any device class
registered with fu_plugin_add_udev_subsystem().
Additionally, the events are rate limited to avoid causing lots of extra plugin
processing when replugging hardware.
This difficult to debug bug only showed up when the fwupd service was stopped,
which the user never noticed, but services like abrt were still keen to report.
The root issue was that the call to fu_plugin_get_smbios_data() in
fu-plugin-uefi.c:fu_plugin_startup() was freeing the returned const GBytes,
which rippled down all the way to a double-free deep in libxmlb.
It's somewhat unusual to have a const GBytes, so just change the plugin helper
to returned a ref'd copy, on the logic a potential 16 byte memory leak is better
than a double-free when the next plugin gets the logic the wrong way around.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1734746
The debug features the object provides are not useful and are much too verbose
to be useful.
Backport the new reader/writer g_autoptr defines to avoid bumping the GLib dep.
Most of the work was done by Kalev Lember <klember@redhat.com>, many thanks.
Some devices (e.g. Wacom, DFU and SuperIO) require the device to be in
'bootloader' mode before the device checksums can be populated.
Rather than each plugin handle both the open()->detach()->detach()->close()
sequence handle this in the plugin loader. It's not super-easy to do the right
thing for the failure case, and having two new dedicated vfuncs makes it a lot
simpler.
This is intended for devices that it is not safe to immediately activate
the firmware. It may be called at a more convenient time instead.
Both fwupdmgr and fwupdtool support the feature.
- if called at runtime with fwupdmgr it uses the daemon
- during shutdown fwupdtool uses the pending.db to perform this feature.
Plugins are allowed to 'opt-out' of this behaviour using _RULE_INHIBITS_IDLE.
This should be used where waking up the hardware to coldplug is expensive,
either from a power consumption point of view, or if other artifacts are going
to be seem -- for instance if the screen flickers when probing display devices.
This functionality is also inhibited when the actual upgrade is happening,
for obvious reasons.
Admins can turn off this auto-sleep behaviour by editing the daemon.conf file.
Fixes https://github.com/hughsie/fwupd/issues/417
This means we don't have to have all the thousands of GUIDs as tiny allocated
strings being passed around to all plugins in a GPtrArray.
This also reduces our heap usage by about 6%.
Now devices can have multiple GUIDs and do not share platform IDs there is
really no point waiting to add the device.
This allows us to remove a whole lot of code for this now-unused functionality.
It wasn't hugely clear what the platform ID was actually meant to represent. In
some cases it was being used like a physical ID, in others it was a logical ID,
and in others it was both. In some cases it was even used as a sysfs path.
Clear up all the confusion by splitting the platform ID into two parts, an
optional *physical* ID to represent the electrical connection, and an optional
*logical* ID to disambiguate composite devices with the same physical ID.
Also create an explicit sysfs_path getter for FuUdevDevice to make this clear.
This allows WAIT_FOR_REPLUG to always work, rather than depending on the order
that the GUIDs were added, and that the kernel would always return the same
sysfs path (which it doesn't have to do, especially for hidraw devices).
The daemon creates a baseclass of either FuUsbDevice or FuUdevDevice when the
devices are added or coldplugged to match the quirk database and to find out
what plugin to run.
This is proxied to plugins, but they are given the GUsbDevice or GUdevDevice and
the FuDevice is just thrown away. Most plugins either use a FuUsbDevice or
superclassed version like FuNvmeDevice and so we re-create the FuDevice, re-probe
the hardware, re-query the quirk database and then return this to the daemon.
In some cases, plugins actually probe the hardware three times (!) by creating
a FuUsbDevice to get the quirks, so that the plugin knows what kind of
superclass to create, which then itself probes the hardware again.
Passing the temporary FuDevice to the plugins means that the simplest ones can
just fu_plugin_device_add() the passed in object, or create a superclass and
incorporate the actual GUsbDevice and all the GUIDs.
This breaks internal plugin API but speeds up startup substantially and deletes
a lot of code.
This allows us to match non-DeviceID GUIDs, and also GUIDs we don't know how to
generate.
To make this fully useful, search for device quirks when GUIDs are added.
Allowing plugins to 'register' for different udev subsystems in _init() allows
us to move the client to the engine, reducing the number of wakeups considerably
for each device event. It also will reduce the amount of boilerplate code in
each plugin that uses GUdev, much like we have done for GUsb.
