Additionally, if the client does not set the feature flag `fde-warning`,
add an extra paragraph into the update description.
Fixes https://github.com/fwupd/fwupd/issues/3829
This moves the cached metadata location from /var/lib/fwupd/remotes.d
to /var/lib/fwupd/metadata
The former was a bad name as it wasn't a list of remotes, and .d is the
suffix for directories the user can install files into, rather than for
binary content managed entirely by the daemon.
Note that g_assert() should not be used in unit tests, since it is a
no-op when compiling with G_DISABLE_ASSERT. Use g_assert() in production
code, and g_assert_true() in unit tests.
See https://github.com/fwupd/fwupd/issues/3790
This functionality broke a number of releases ago as part of
implementing device inhibition and was just noticed now.
Instead of fixing it, the preference seems to be to remove the
functionality as it exists today as inhibitions can happen for
a number of reasons.
To still allow people to override these power warnings (such as during
development) add a new daemon configuration item that can be used.
Fixes: #3778
Quite a few plugins are using a FuDeviceLocker to detach then attach in
the error path, and finding them isn't easy as we explicitly cast to a
FuDeviceLockerFunc.
For sanity, just provide both symbols so we can do the right thing in
both cases. It seems like a sensible thing to allow.
Fixes https://github.com/fwupd/fwupd/issues/3771
This allows us to do a few things:
* Remove the runtime dep on Python 3, which is tricky for ChromeOS
* Test composite devices more efficiently, only writing once per test
* Automatically upload signed reports for successful device tests.
Checking whether some plugins are enabled or not will require smbios
to be available. Information may be wrongly displayed unless this
has been checked.
CAPE family is Audio DSP for a board range of applications in IOT, PC
and mobile can be interfaced via I2C, UART or USB interface. This patch
is only for CX31993 and CX31988 chips, there is not immediate plans is
to add support to other CAPE devices.
CX31993 have two separate firmware .hid file for for each partition. It
need to convert two .hid files into a .fw file for fwupd tool to
consume.
Currently, this patch is only support for EPOS headsets with basic
firmware update feature. Either new code singing or manifest.xml are
unsupported yet.
The code has been tested with CX31993 EVK board.
A test firmware file is put at 'src/fuzzing/firmware/synaptics-cape.fw'
synaptics-cape: Port to new FuProgress API and style fixups
synaptics-cape: Fix compile errors and add missing test fw file
Signed-off-by: Simon Ho <simon.ho@synaptics.com>
synaptics-cape: Fix fuzzer test
Signed-off-by: Simon Ho <simon.ho@synaptics.com>
synaptics-cape: Fix progress bar number
Signed-off-by: Simon Ho <simon.ho@synaptics.com>
synaptics-cape: Mark the fuzzing target
trivial: Use a stable GLib branch for fuzzing
synaptics-cape: Fix progress bar number
Signed-off-by: Simon Ho <simon.ho@synaptics.com>
synaptics-cape: Fix readme
synaptics-cape: Style fixups
synaptics-cape: Fix progress bar percentage
synaptics-cape: Style fixups
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.
1. Create hsi_history table to store the security attributes.
2. Convert all security entities to a json string and write to database.
Signed-off-by: Kate Hsuan <hpa@redhat.com>
Changes in v1:
1. Fixed typo: "his_history" to "hsi_history"
2. g_autofree all gchar pointer.
3. Removed unnecessary g_warning messages.
4. Moved the json format comment to Document comment.
5. Add an error handling for json converter.
Changes in v2:
1. Declare all pointers using g_auto_ptr.
2. The warning messages of JSON conversion and DB writing errors were added.
3. "Since: 1.7.0" was added to the document comment.
Changes in v3:
1. Fix variable declaration.
2. Remove unecessary data type casting.
Changes in v4:
1. Fix migration schema.
Changes in v5:
1. Fix hsi_history column name declaration.
Changes in v6:
Column name was modified from last to timestamp.
This makes devices that come back in bootloader mode with no children
timeout, which is bad UX. We don't even need the feature now that we
can WAIT_FOR_REPLUG on multiple devices now.
* dell-dock: open usb4 device in the activate call, and leave early
* trivial: read history earlier, at least before plugin register
* dell-dock: activate usb4 device exclusively if it needs activation
All the other vfuncs have 'plugin, device, flags' but prepare and
cleanup vfuncs being 'plugin, flags, device' order has been triggering
my OCD for the last few years.
We've just broken the symbol names, so it's the right time to fix this.
More than one person has asked about 'why call fu_plugin_update() for a
reinstall or downgrade' and I didn't have a very good answer.
The plugin API is not officially stable, and we should fix things to be
less confusing. Use the same verbs as the FuDevice vfuncs instead.
This speeds up fu-self-test, but more importantly fixes a intermittent
'ninja check' failure when a host USB device disconnects at exactly the
wrong time.
The FuUsbBackend code is unusual in that the setup() code sets up a
context (with a thread) which takes up to 2 seconds to timeout.
We don't want to show the big warning about the missing ESRT on server
hardware that is managed by a BMC:
WARNING: UEFI capsule updates not available or enabled in firmware setup
See https://github.com/fwupd/fwupd/wiki/PluginFlag:capsules-unsupported for more information.
