proxmox-mirrors/fwupd
1
0
Fork 0
mirror of https://git.proxmox.com/git/fwupd synced 2025-05-28 15:05:53 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

trivial: Update the README

Browse Source 
We now have LVFS as an option :)
This commit is contained in:
Richard Hughes 2015-06-25 16:40:39 +01:00
parent ae0efdc5a7
commit ffd2c8b328
1 changed files with 15 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
README.md
View File

@ -23,27 +23,14 @@ isn't so useful, and so Microsoft have decided we should all package it up in a
update in more detail. The .inf file gives us the hardware ID of what the
firmware is referring to, as well as the vendor and a short update description.
So far the update descriptions have been less than awesome so we also need some
way of fixing up some of the update descriptions to be suitable to show the user.
I'm asking friendly upstream vendors to start shipping a MetaInfo file alongside
I'm asking friendly upstream vendors to also include a MetaInfo file alongside
the .inf file in the firmware .cab file. This means we can have fully localized
update descriptions, along with all the usual things you'd expect from an
update, e.g. the upstream vendor, the licensing information, etc.
Of course, a lot of vendors are not going to care about good descriptions, and
won't be interested in shipping another file in the update just for Linux users.
For that, we can actually "inject" a replacement MetaInfo file when we curate
the AppStream metadata. This allows us to download all the .cab files we care
about, but are not allowed to redistribute, run the `appstream-builder` on them,
then package up just the XML metadata which can be consumed by pretty much any
distribution tool.
A lot of people don't have UEFI hardware that is capable of applying capsule
firmware updates, so I've also added a ColorHug provider, which predictably also
lets you update the firmware on your ColorHug device. It's a lot lower risk
testing all this code with a £20 device than your nice shiny expensive prototype
hardware.
lets you update the firmware on your ColorHug devices.
I'm also happy to accept patches for other hardware that supports updates,
although the internal API isn't 100% stable yet. The provider concept allows
@ -56,10 +43,8 @@ isn't rocket science.
What is standardised is the metadata, using AppStream 0.9 as the interchange
format. A lot of tools already talk AppStream and so this makes working with
other desktop and server tools very easy. Actually generating the AppStream
metadata can either be done using using `appstream-builder`, or some random
vendor-specific non-free Perl/C++/awk script that operates on internal data;
the point is that as long as the output format is AppStream and the metadata
GUID matches the hardware GUID we don't really care.
metadata can either be done using using `appstream-builder` or the Linux
Vendor Firmware Service.
Security
--------
@ -209,8 +194,8 @@ An example `.metainfo.xml` file might look like this:
If the firmware is not redistributable you have to indicate it in in the
`.metainfo.xml` file with `<project_license>proprietary</project_license>`.
It is then **very important** you also provide a download location in the
`.metainfo.xml` file.
If the firmware location is not stable you can use the Linux Vendor Firmware
Service to mirror your file.
Questions
---------
@ -228,8 +213,12 @@ tool available from the [appstream-glib](https://github.com/hughsie/appstream-gl
### Where do I submit the `.cab` files?
The end goal is for vendors to produce and upload the AppStream metadata
themselves using the `appstream-builder` command line tool, for example:
The easiest way to upload new firmware is to use the [Linux Vendor Firmware
Service](https://beta-lvfs.rhcloud.com/) which will validate your firmware,
generate the metadata and mirror them automatically.
Vendors can also produce and upload the AppStream metadata themselves using the
`appstream-builder` command line tool, for example:
```sh
appstream-builder \
@ -240,15 +229,15 @@ appstream-builder \
...will produce this file: http://www.hughski.com/downloads/colorhug-firmware.xml
Please [email us](mailto://richard@hughsie.com) if you just want to upload `.cab`
files and you would like us to generate metadata for your product.
Please [email us](mailto://richard@hughsie.com) if you want more help using
either generation method.
### How does fwupd know the device firmware version?
For generic USB devices you can use a firmware vendor extensions that are used
by a few OpenHardware projects. This means the fwupd daemon can obtain the
GUID and firmware version without claiming the interface on the device and
preventing other software from using it straight away.
preventing other software from using it.
For closed-source devices a product-specific provider can also be used, although
this isn't covered here.