diff --git a/README.md b/README.md index bd00bb7f1..f35bfa400 100644 --- a/README.md +++ b/README.md @@ -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 `proprietary`. -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.