Are there any major differences between these two methods? E.g. are there things you can do with the IDE that you can’t with Chrysalis? The documentation is a bit minimal and maybe a bit outdated.
With the Arduino IDE, you’re compiling custom firmware, and have the full power of Arduino and Kaleidoscope available to you.
With Chrysalis, you’re not compiling firmware, it talks to the firmware on the keyboard over USB Serial using a custom protocol. Chrysalis can only configure or change things that the firmware is capable of. You can’t add new features, new functionality that the firmware does not already provide.
As such, there’s a lot you can do with custom firmware that you cannot do with Chrysalis. Chrysalis does provide a reasonably large set of configurable things, but it’s just that - configuration. With custom firmware, you’re not limited to configuration, you can write code, too. You can include more plugins, or disable others. You can write custom stuff, perhaps even a plugin of your own. The only limitation is your imagination (and storage space on the device, but there’s plenty of that too).
I have been a Model 01 user since the early days and I have been flashing my own firmware all the time.
Yesterday I gave Chrysalis a try, for maybe the third time. And finally I feel happy with the experience!
Don’t know if it a new feature or it was just hard to discover, but what made me happy was the ability to visualize a layer at the time using the layer list on the right. But once discovered, I feel I can do everything I can think of with Chrysalis 
Kudos to the developers. Good work! 
1 Like
I’d been seeing weird interactions between the custom firmware and EEPROM, so I did a factory reset with Chrysalis & reloaded the custom firmware. The board still booted to the EEPROM first though and all the keys were offset or shifted in strange ways — the weirdest was that E made the PC sleep, even though that’s Super+AltGR.
LeftFun+Shift+Prog brought normality back, but this has left me a bit more confused about how these different ways of configuring things are meant to interact.
Are the Chrysalis settings supposed to overlay the firmware, a bit like another set of layers?
At the moment, the layers look completely messed up in Chrysalis, mostly 5-digit numbers.
I’ve rechecked my steps and what seems to cause this corruption is flashing from Arduino after booting the keyboard with Prog held down (the only way I can flash from the IDE atm). Flashing from Chrysalis works fine, but is very slow & tedious. It would be a bit easier if it remembered your last custom firmware file.
How the built-in and eeprom layers interact is controlled by the keymap.onlyCustom setting. Chrysalis requires this to be on, which means that only the layers in EEPROM will be used, and the builtin ones are ignored.
If you do not intend to use EEPROM layers, I’d recommend disabling the EEPROMKeymap plugin in your custom sketch, or setting keymap.onlyCustom to 0 (via the bin/focus-send tool in the Kaleidoscope sources, for example), and not let Chrysalis change it back to 1.
This is most likely because of how Kaleidoscope’s EEPROM handling is implemented. It’s a very simple thing: each plugin can request a slice, and they’ll get it (if there’s available space in eeprom). The next plugin that requests a slice, will have an offset that starts right after the previous slice.
In practice, this means that if you enable or disable plugins that use EEPROM, the layout may change from one firmware version to another, and the firmware itself has no way of knowing that. This is one of the reasons why Chrysalis flashing is slow: it takes a structured snapshot of the EEPROM, and then restores it after flashing.
Luckily, Kaleidoscope recently had a few scripts added that make it easier to do the kind of backup/restore Chrysalis does. More info about them are now in the docs: Using EEPROM — Kaleidoscope documentation
If …
…does this mean “never use Chrysalis again” ?
I’d hoped that commenting this would mean the firmware keymap was the default.
// If there's a default layer set in EEPROM, we should set that as the default
// here.
// Layer.move(EEPROMSettings.default_layer());
The odd thing is that Chrysalis showed a layer 3 even after I’d done a factory reset. I suppose I must have used Chrysalis to create a draft of the layer I later made in the IDE, but I don’t understand how it survived. Maybe it’s a little too enthusiastic at restoring the EEPROM.
So, if you want to use both IDE & Chrysalis (if that’s possible), you should only create the keymaps in Chrysalis (or mirror them exactly)?
BTW booting with Prog then flashing using Chrysalis also scrambles the EEPROM keymaps at the moment.
If you never intend to use EEPROM layers, then it’s best to disable them in the firmware. If for some reason you can’t, or don’t want to, Chrysalis can still function, it just won’t be able to edit your keymap (or colormap, for that matter, because the two are tied within Chrysalis). It will still be able to flash, and configure other plugins on your keyboard.
So no, it does not mean “don’t use Chrysalis”. It means that when it prompts you to enable custom layers only, you don’t click the enable button.
The number of layers is fixed at compile time. EEPROMKeymap.setup(8) for example reserves space for 8 layers. Chrysalis will, by default, show all layers that aren’t empty, and can show empty ones on top. It will also copy the built-in layers to EEPROM on first connect, if the EEPROM keymap is empty - this is done so that there’s something to edit, since Chrysalis can’t edit built-in keymaps.
Yes. This is what Chrysalis does when it sees an empty keymap in EEPROM: it copies the built-in one.
As far as Chrysalis is concerned, the built-in keymap serves as a default, something to go back to if need be, but otherwise it’s just a template of sorts, not something to work with directly.
That’s kind of normal, if the layout of EEPROM changes. I described it in short in my previous post.
Normally, when flashing from application mode (ie, without the Prog trick), Chrysalis will make a backup of EEPROM, and restore it after - this makes it possible to have changing EEPROM layouts, because the restore will rearrange it properly. When flashing from bootloader mode (with the Prog trick), it can’t make a backup, because the bootloader knows nothing about that, so it can’t restore it either.