Feature request: Distribute firmware updates via fwupd?

[jwillikers]

It would be really cool if firmware updates were available for Keyboardio's keyboards via fwupd on Linux.
That would make it really easy to get the latest updates on Linux, since fwupd is pretty well integrated in most desktop Linux distributions out-of-box.
Users could update by checking for updates with fwupd or a higher-level tool like GNOME Firmware, which can provide necessary instructions for the update, such as holding a particular combination of keys when initiating the update.

Since I'm so happy with the defaults of my Keyboardio keyboards, I don't often need the advanced features of Chrysalis. I usually just set my preferred keyboard layout once, and then only use Chrysalis for firmware updates.

I know that System76 does this for their Launch keyboard, as described here.

[algernon]

This sounds like a very good idea to me, I like it. I'll look into it, thanks!

[algernon]

FWIW, I will be looking into this in the not too distant future, mostly exploring what needs to be done, if it is even feasible. I'll document my findings here, but I will very likely not take it further than the research stage. We'll have a reasonable set of tasks at that point, however, and I'll happily review patches.

[jwillikers]

I'm pretty interested in learning about how it works, so I'm also interested in helping out.

[algernon]

From what I can tell, we'll need to do two different things to make this possible:

1. We'll need to register as a hardware vendor on LVFS, and figure out how the release process works there.
2. We'll need to write a plugin for fwupd to handle our update procedures, like the EEPROM backup & restore stuff.

I'm not sure how the plugins are organized in fwupd, but we'll need a way to follow the same logic Chrysalis does: structured EEPROM backup, reboot to bootloader, flash (multiple protocols supported here: DFU for the Model100, and others for the Keyboardio Atreus/Model01, and another for the ErgoDox EZ and OG Atreus, and another for Splitography), reconnect, erase eeprom, reconnect again, restore eeprom.

fwupd is written in C. The process requires multiple reboots of the device, one of them requiring a reboot into bootloader mode, which requires the user to hold a key, so the process cannot be fully automated.

This sounds like a recipe for disaster to me. The flashing process is proving to be quite fragile even in a higher level language, I do not see it working out well when written in C.

If we were just flashing, that could work, the DFU plugin already exists, so we'd only need to bolt on a plugin that helps us do the reboot into bootloader mode. But just flashing, without the eeprom save & restore dance, the update would do more harm than good.