proxmox-mirrors/fwupd
1
0
Fork 0
mirror of https://git.proxmox.com/git/fwupd synced 2025-05-29 20:32:50 +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 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. 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 I'm asking friendly upstream vendors to also include a MetaInfo file alongside
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
the .inf file in the firmware .cab file. This means we can have fully localized 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 descriptions, along with all the usual things you'd expect from an
update, e.g. the upstream vendor, the licensing information, etc. 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 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 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 lets you update the firmware on your ColorHug devices.
testing all this code with a £20 device than your nice shiny expensive prototype
hardware.
I'm also happy to accept patches for other hardware that supports updates, 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 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 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 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 other desktop and server tools very easy. Actually generating the AppStream
metadata can either be done using using `appstream-builder`, or some random metadata can either be done using using `appstream-builder` or the Linux
vendor-specific non-free Perl/C++/awk script that operates on internal data; Vendor Firmware Service.
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.
Security 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 If the firmware is not redistributable you have to indicate it in in the
`.metainfo.xml` file with `<project_license>proprietary</project_license>`. `.metainfo.xml` file with `<project_license>proprietary</project_license>`.
It is then **very important** you also provide a download location in the If the firmware location is not stable you can use the Linux Vendor Firmware
`.metainfo.xml` file. Service to mirror your file.
Questions Questions
--------- ---------
@ -228,8 +213,12 @@ tool available from the [appstream-glib](https://github.com/hughsie/appstream-gl
### Where do I submit the `.cab` files? ### Where do I submit the `.cab` files?
The end goal is for vendors to produce and upload the AppStream metadata The easiest way to upload new firmware is to use the [Linux Vendor Firmware
themselves using the `appstream-builder` command line tool, for example: 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 ```sh
appstream-builder \ appstream-builder \
@ -240,15 +229,15 @@ appstream-builder \
...will produce this file: http://www.hughski.com/downloads/colorhug-firmware.xml ...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` Please [email us](mailto://richard@hughsie.com) if you want more help using
files and you would like us to generate metadata for your product. either generation method.
### How does fwupd know the device firmware version? ### How does fwupd know the device firmware version?
For generic USB devices you can use a firmware vendor extensions that are used 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 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 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 For closed-source devices a product-specific provider can also be used, although
this isn't covered here. this isn't covered here.