This includes snapshot data like GUdevDevice that is only very rarely useful
after `FuDevice->probe()` has been completed. Add a warning so that we can
identify affected plugins and provide some grace period.
This should reduce the idle RSS by ~200kB when we flip the swithc in the future.
The kernel should have loaded hidraw support by the time that we probe
a device. This fixes logitech devices not showing up after startup
if they weren't plugged in initially.
Fixes: #5525
This allows us to ignore all the delays when the device is emulated, with the
idea being to do dozens of device emulations in the CI tests.
Also, do not call fu_progress_sleep() when the device is emulated.
Now incorporate is fixed to copy across the properties we need in the
superclass, we don't need to do the subclass ->probe().
Note, we still need to do the subclassed ->probe() when using
FU_UDEV_DEVICE_FLAG_VENDOR_FROM_PARENT or when looking at properties
on the parent device.
This also removes the spurious 'already set GType to FuVliUsbhubDevice,
ignoring FuVliUsbhubDevice' messages when running the daemon.
Some plugins were creating local versions (which were not attached to
the daemon progress in any way) as a workaround as they needed to do
actions that took a long time to complete.
Provide a device instance builder that allows plugins to easily
create multiple instance IDs based on parent attributes.
Also fix a lot of the instance ID orders, so that we add more generic
IDs first, and more specific IDs after.
The restart message is supposed to be HIDPP_REPORT_ID_LONG according to
the specs, but it works just as well if we use
HIDPP_REPORT_ID_SHORT. We better stick to the specs, though.
It's actually quite hard to build a front-end for fwupd at the moment
as you're never sure when the progress bar is going to zip back to 0%
and start all over again. Some plugins go 0..100% for write, others
go 0..100% for erase, then again for write, then *again* for verify.
By creating a helper object we can easily split up the progress of the
specific task, e.g. write_firmware().
We can encode at the plugin level "the erase takes 50% of the time, the
write takes 40% and the read takes 10%". This means we can have a
progressbar which goes up just once at a consistent speed.
