Model 100 keymap appears scrambled in Chrysalis after firmware update

[blm768]

Describe the bug After this commit (or somewhere nearby, but definitely after this one), compiling and flashing the firmware leaves my Model 100 in a state where everything in the keymap appears shifted over several columns in Chrysalis. I haven't had the chance to thoroughly test the actual key behavior yet, but it's definitely wrong if I reload the stock QWERTY layout and try to flash that to EEPROM. It looks like Chrysalis (or the firmware) is just confused as to which keymap slots map to actual physical keys.

To Reproduce

1. Check out the affected commit. (My Arduino setup is a bit broken at the moment, so I'm having trouble isolating the specific commit, but I can try to debug further on another machine when I have more time.)
2. Run make flash from the Model100 directory.
3. Attach to the keyboard in Chrysalis

Expected behavior I'd expect my keymap to appear the same in Chrysalis as it did with the previous firmware.

Environment (please complete the following information):

• OS: NixOS
• Version: 22.05
• Device: Keyboardio Model 100

Additional context I'd probably better test this on my Windows machine just in case something's weird with my NixOS setup, so don't spend a ton of time trying to track this down, especially if it doesn't reproduce easily.

[Kethku]

I'm also encountering this issue with the model 100 I just received on windows 11 with firmware 1.99.7

[algernon]

This is most likely because the EEPROM layout changed between versions. Did either of you flash via Chrysalis, or via the Arduino IDE or the CLI?

Chrysalis performs a number of extra steps to migrate the EEPROM contents, the other paths (arduino ide, make) do not currently do this, so the migration has to be performed manually. The bin/eeprom-backup.sh and bin/eeprom-restore.sh scripts in recent Kaleidoscope can be used for this purpose, documentation for them are available here. Alternatively, you can also use the focus tool provided by kaleidoscope-focus.rs (pre-built binaries here): focus backup >backup.json before flashing, and focus restore <backup.json to restore after. It's probably a good idea to erase eeprom in between, which can be done by focus send eeprom.erase (or bin/focus-send eeprom.erase using the focus-send script in Kaleidoscope itself).

[blm768]

I flashed via the CLI since I was having issues getting Chrysalis to cooperate; those are probably ironed out in the latest release, so I'll have to try that. I guess literally any change in EEPROM layout would have the effect I noticed unless all offset changes were after the keymap, so I should probably be less surprised that the layout would experience some weirdness. It might not be a terrible idea to embed some kind of versioning in the EEPROM data if that's not already in there, although there's only so much we could do with that on the keyboard side. I totally missed the section in the docs about the EEPROM stuff; we could probably use a link from the README to the docs, and from the "Install the Firmware" section to the "Migrating EEPROM Contents" section.

The kaleidoscope-focus.rs tool looks really interesting, so I'll have to mess with that. While I was waiting for my Model 100, I built some Rust-based firmware for a little ARM-powered macro keypad, and I was just starting to look into host/device communication to make the keypad react to things like switching between applications. With a Rust library for comms with the Model 100, I could control both of those from the same desktop app.

[blm768]

Ah, the README actually does have a link to the docs. I just skipped it because I was using the CLI.

[blm768]

I think Pull Request #1291 may be enough to mitigate this.