Support for fwupd - Linux Vendor Firmware Service

[shiftee]

Would it be possible to support firmware updates via fwupd?

fwupd is an open-source daemon for managing the installation of firmware updates on Linux-based systems: wikipedia

Support for this would provide trivial firmware updates across all Linux distros.

I am happy to help out with this if you wish.

• Device:
  Kira - (Kono Store March 2020)
  Any other dfu updatable products would also be appreciated.

• Firmware Origin:
  Factory supplied firmware

• OS:
  Ubuntu 20.04

• Version:
  bcdDevice 4.07

• Reproduction Steps:
  N/A

• Resulting Issue:
  See this blog post by the fwupd project maintainer:
  https://blogs.gnome.org/hughsie/2019/11/18/google-and-fwupd

[haata]

I've had some cursory awareness of this project for a number of years now. It seems like things have started to really take off (yay!).

(don't let this wall of text discourage you, I'm genuinely interested; but this might be a bit more complicated than it first seems!)

Some good things about the current architecture

• Uses standard dfu (even supports detach properly)
• Most recent devices (starting with Kira and some Whitefoxes) have an official USB VID:PID. Earlier devices have a fake VID:PID for the bootloader.

Some potential issues

• Currently, the layout (and animation) files are bundled with the firmware update. I do plan on fixing this in the future, but this may take a long time (and there are some limitations).
• I'm working on a device that has two different firmwares using different Altsettings (standard dfu feature), is this supported?
• The bootloader (since the K-Type in 2017) has two different modes
  • Bypass, which can flash any firmware. Requires either a keyboard shortcut be pressed or the flash button on the back of the keyboard be pressed (this is the current standard method of flashing). If firmware flashing fails for any reason (and the firmware is intact), the firmware will reset to the Secure mode bootloader.
  • Secure, which requires a one-time generated key be prepended to the firmware before loading. This key must be requested from the running firmware before switching from the firmware to the bootloader, this action requires physical interaction with the keyboard (usually a prompted keypress). The bootloader has no ability to provide this information (this is on purpose so it's not possible to flash unwarranted firmware to the device). If flashing fails, the key is invalidated and another key must be requested and prepended to the firmware; this request further physical interaction. More details are documented here: https://github.com/kiibohd/controller/tree/master/Bootloader
• Firmware should not be upgraded automatically (under any circumstances) for a few reasons
  • Failure may temporarily brick the keyboard (if corruption occurs). Another firmware will have to be loaded.
  • Keyboard is non-functional while firmware update proceeding
  • It's possible to cancel the firmware update on some versions of the bootloader and corrupt the firmware by pressing the Esc key (updating the bootloader ranges from near-impossible to almost painless for the end-user depending on which keyboard they have; the intention is to never update the bootloader).
  • Some users have customized firmware (layouts, options, animations), these will be lost with an automatic firmware update. The standard usage of GUIDs (https://lvfs.readthedocs.io/en/latest/metainfo.html#using-guids) might not work as the vendor+product+revision are not unique to any configuration. Just to the firmware version. The revision is an incrementing number based off the commit number of the build tree.
• Users with stock firmware might be able to have their firmwares updated automatically, but I'm not sure there is a good way of validating this, even when running from the firmware. It might be possible to "upload" the firmware (dfu terminology) to the host computer and compare with official versions. HID-IO, which is an interface I'm working on could solve this problem.

Some other questions

• Would Input Club be considered an IHV? There are a few cases where we might be considered an ODM as well.
• How complicated is the release process? Right now we have at least 16 different firmwares that get released per version update (and this number is growing).
• Would the first step be requesting an account?

[shiftee]

Altsettings:

Devices with multiple firmwares are supported. I'm not sure about the alt settings but it is mentioned in the code which bodes well.

Firmware is never updated automatically:

If there are updates that need applying then they are downloaded and the user is notified and the update details are shown in the specified language. The user has to explicitly agree to the firmware update action before the update is performed. Source

I'm not too sure about the rest, I would suggest you go ahead and request an account.
If you link to this issue they will hopefully provide a few answers

[haata]

I've put in a request for an account.

[shiftee]

Did you hear anything back?

[haata]

I never got a reply back to the email to [email protected] (sent it on May 11th).

[shiftee]

Let's try poking the bear :)
@hughsie

[hughsie]

The bear apologizes profusely. There was 3 weeks where the info@ redirect was sending emails to /dev/null, so we assassinated the sysadmin. Could you please send me the email again please and I'll get things set up for you to experiment with. Thanks!

[haata]

Np, will send again.

[hughsie]

Urgh, on the assumption you've sent it, I've not got it. I've just tested it again, and it's broken: I've got suitably stroppy at the people responsible. Can you sent it to [email protected] please.

[haata]

Sent to your address.

[shiftee]

Just wondering if there's any update on this?

[haata]

I got everything I needed to start work. I owe hughsie a pcb for testing, and I need to put together a basic firmware for updating. I've been a bit busy though...
I might work on this a bit this weekend as a change of pace.