Users are getting confused when they're being told that AC power is required
when they are already on AC power... but the battery is too low to perform the
update.
Rather than wrapping every sync D-Bus call with a GTask helper (hundreds of
additional lines of code and dozens of new entrypoints in libfwupd) I think it
is best for client software wanting async operation just uses the D-Bus
interface. I consider it part of the API as much as the shared library and
I don't see it changing in a non-compatible way any time soon.
Exposing these already-exported symbols allows client software to use the
demarshalling functionality and to operate on the GObjects directly from an
existing GDBus async return value.
I'm getting a bit fed up with failed reports from arch users where they just
have a broken system. I don't think it's useful to upload to the LVFS or notify
the vendor about failures like this.
This allows several things, for instance:
* Adding or removing blacklisted plugins or devices
* Changing the idle timeout where allowed
...without a user needing to manually modify a configuration file.
Some firmwares only update one part of the system, e.g. the EC or ME firmware.
Other updates include all the updates needed for the whole system, and vendors
have been doing different things with the component name due to this.
To fix, add an enumerated set of firmware 'categories' that can be set by the
uploader in the metainfo.xml file (or changed the LVFS) which automatically
set the name suffix.
Only append the translated version in the client when <categories> has
not been set, as the LVFS is still operating in compatibility mode and setting
the <name> with the prefix. Add the support to fwupd now so we can switch in
about 9 months time.
On some hardware the SHA1 checksum is not set and so we want to use the SHA256
hash value as well.
The LVFS doesn't currently read the ChecksumDevice value and so nothing will
explode serverside when changing this type from 'string' to 'array of strings'.
This allows us to one day implement 'reinstall', allows us to have a more useful
`get-releases` command and also means we can add other reasons for blocking the
release in the future.
In the future we'll want to use this flag to signify if the release is an
upgrade, downgrade, below the version-lowest, or if it is locked in some way.
This feature is turned on with the new fwupdtool option `--enable-json-state`
The intended use case is for ChromeOS to be able to save information about
devices on the system when `fwupdtool update` was run to display in the UX at
a later time.
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.
This also allows us to write mixed-endian structures and adds tests. As part of
this commit we've also changed the API of something that's not yet been in any
tarball release, so no pitchforks please.
This allows hardware from OEMs to *not* match generic firmware supplied by the
device manufacturer. The idea being, that the OEM will supply firmware that
will actually work on the device.
Based on a patch from Mario Limonciello, many thanks.
This makes it much easier to write metainfo files as we don't have to ask OEMs
or ODMs to run fwupdtool or fwupd with --verbose and then sort through hundreds
of debugging statements.
The fwupdmgr get-devices output also now prints output like this:
20EQS64N0C System Firmware
Guid: ddc0ee61-e7f0-4e7d-acc5-c070a398838e
Guid: 40ce5954-bfa8-5762-926b-f4848cb28bc8 <- UEFI\RES_{DDC0EE61-E7F0-4E7D-ACC5-C070A398838E}
We're deliberately not showing the InstanceId lines in the get-updates command
as the instance IDs are not useful in this case. It will also only show the
InstanceID lines when run as a trusted user, for instance root.
Replace the non-breaking space with a traditional space rather than changing
the expected output with #ifdef to allow running the tests with a daemon
compiled against an older glib2 version.
The idea is that if the user should know something about the device update
"after" it's succesfully completed then the plugin can set `UpdateMessage`
for the device and a client can show it.
An example would be a device that doesn't reboot on its own and the user
needs to power cycle it manually.
The source URL allows us to comply with our various obligations when shipping
firmware built from GPL licensed sources. The details URL allows vendors to
include a link to a full HTML details page about the specific release.
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
These are set from the AppStream metadata and are specific to the firmware
release.
If not provided, the install duration falls back to the per-device duration
values which can be set in the quirk files.
