Everything seemed to work (compiles, upload firmware, progress bar etc…) but the resulting layout is entirely broken, with almost every key mapping to a modifier-key (one key mapped to shutdown, I stopped testing after that).
Is this a known issue, are others happily building layouts using kaleidoscope with the model 100? (tested a couple of GIT rev’s in case this was a recent error but both produced unusable key-maps).
Is there a “stable” GIT tag for Kaleidoscope which I could use to avoid running into potential errors introduced as part of regular development?
Hi @ideasman42 I was in the same boat as you, have compiled custom firmware for a few QMK boards but never tried Kaleidoscope - I naively imagined by the time I got my Model 100 the port to QMK wouldn’t be far behind, but as seen in this recent post here you’re right, it doesn’t seem straightforward and who knows how far off the port might be - well I sure as hell wasn’t going to let my Model 100 collect dust waiting, so I just had a look at the Kaleidoscope docs and figured it out.
First, did you update the firmware? Without that, you will get the corrupted layers that is a known bug in the earlier firmware the keyboards shipped with.
Second, I installed Arduino IDE (as per the steps in the docs), then built my layout by editing the default firmware until it matched what I wanted, then compiled (this took me a few attempts to get the code right as I’d never done it before, and I’m not a programmer). Basically I just took my typical QMK keymap and figured out how to transpose it to its Kaleidoscope equivalent. I was woried that I couldn’t get Kaleidoscope to do all the tricks QMK does, but managed to get it all in there. I just need to tweak some settings with QuKeys (mod-tap) and I probably won’t even bother flashing QMK now, who knows.
Lastly, you can flash the keyboard with Arduino IDE by plugging it in holding the Prog key.
Have you used Chrysalis before flashing your own firmware? If you did, and your own sketch has the EEPROMKeymap plugin enabled, then it is very likely that what you’re seeing is the keymap in EEPROM is being used, rather than the one in the sketch. If you’ve removed plugins, or rearranged them, that may have altered the EEPROM layout, which is why it may appear as garbage.
(Chrysalis works possible eeprom layout changes around by taking a structured dump of the eeprom, and restoring it after flashing, something that the Arduino tooling is not doing yet.)
I’m using the Kaleidoscope just fine with make flash in the example script directory. I used the upstream and then ported my model01 config over and all the functionality I use is working.
Thanks for the helpful replies, I’ll investigate a solution when I get a chance.
From the answers so far I have some ideas how the issue might be resolved.
NOTE: it was surprising to me that there is a difference between flashing from Chrysalis / command-line. That they would even interact at all, I did apply the upgrade but can’t recall if it was before/after attempting to build a layout, so I’ll try the suggestions mentioned.
I’m happy to see there are some QMK users here looking into Kaleidoscope; I really want to reimplement some of the features I wrote for my QMK-based Keebio FoldKB in Kaleidoscope for my Model 100 – especially getting the LEDs to all blink when the caps lock is on.
QMK was pretty straightforward for me to wrap my head around: there are hook functions in a bunch of places in the event loop, and if you want to do something special at that point, implement something for the hook. I’ve just started looking at Kaleidoscope, but it’s not clear to me how the idea of “hook functions” would translate into Kaleidoscope code.
If anyone could offer me some hints to get me started, coming as I am from the QMK perspective, I’d really appreciate it.
Kaleidoscope is using a plugin system, where each plugin can implement certain event handlers, those are analogous to the hooks in QMK. For example, if you want to run some code whenever a layer changes, you can write a plugin that implements the onLayerChange() event handler. Most of the event handlers are documented here:
As far as I see, the only one not documented there is onFocusEvent(const char *input). An example of that is shown in the FocusSerial docs at FocusSerial — Kaleidoscope documentation.
The Kaleidoscope docs have a (work in progress) section about writing plugins, too, which might be useful to you:
You can also look at the Kaleidoscope source, most functionality of the firmware are implemented as plugins, plenty of them there to borrow ideas from!
