RP2040 - go QMK or KMK?

Hi all, due to killing my pro micro and the extremely risen prices for them, I decided to go with the KB2040 for the next builds. Now, the QMK documentation for the 2040 is…I call it lacking. On my research I also found the KMK firmware project, which really sounds a lot more innovative and modern for me.
Now I have to say, I dont have that much QMK experience in the coding section. I built a keymap in C, started porting the board to VIAL and now the MCU is broken. So I´m thinking of going the route to switch to KMK.

Do any of you have experience with the different FWs? What would you recommend? Is there aynthing that would be a nogo for KMK for you and go QMK instead?

I’m not down in the nitty gritty of either, having only seen KMK mentioned recently, but I have modified keymaps and toggled options to build my own firmware in QMK. So I’m a user of the software, not a developer.

That said, if the user experience with KMK is better than QMK that might be good for a go. QMK requires a lot out of the user in terms of setup and working the tool via the command line. Conversely, it seems like KMK may be a bit on the fringe at the current time and I’d question how well it gets accepted. So going with QMK would be a safe bet albeit not the most user friendly or from what you’re saying, the best option for RP2040 based boards.

For what it’s worth, I think development for the RP2040 is really cool.

Just my thoughts.

If you know Python and never touched both KMK and QMK, i’d say KMK will probably give you positive results quickier.

QMK need some learning curve, RP2040 documentation is as of now less complete and a bit hidden in the QMK repo, but it may be a good investment in the end.
And specially if you are a VIA user, having a VIA compatible firmware will allow you to tweak your layout without touching a line of code.

A bit of RP2040 support status on QMK:
Early support is officially merged into master branch.
But QMK VIAL fork does not have yet official support, although some people did the tedious merge work in their own repo like Zykrah: GitHub - zykrah/qmk_firmware: Open-source keyboard firmware for Atmel AVR and Arm USB families
For my own development needs I have yet to find a problem in Zykrah fork that I intensively use in my own RP2040 project, the Leyden Jar.

Well I never touched QMK that much, really just adjusted a keymap a bit and started porting to VIAL. No VIAL support is a bit of a downside imho, I prefer that way over VIA.

But, I dont really have any real codig experience, but was thinking about learning Python. Thats whats tempting me even more on the KMK firmware. I like the idea of just adjusting the keymap file on KMK without having to compile and flash again, I think I can live without VIA(L) support then for now. Also mostly only happens when Im getting a new project, adjusting things a bit while using or switching between formfactors again and being not sure what key is mapped where on which layer (yes I should implement some kind of my own standard there…)

Currently Im still waiting for them to arrive, but I guess Ill give KMK a try first.

1 Like

Does not cost to test CircuitPython with KMK first, then later have a look at QMK/VIAL when the merge will be done.

1 Like

I’m quite fond of KMK for not needing to compile anything or have a workflow installed to make changes, just save the file in a text editor and it’s there. Additionally, I’m happy enough with the featureset and the ability to very easily just slap other CircuitPython libraries into it that I’m using it as my primary choice for future projects of mine.
Sometimes documentation is a bit lacking, but it hasn’t had nearly the time or volunteer commitment that QMK has had to polish docs up, and their discord is more than willing to help. If a gui tool like Vial is a must-have for you, Peg is the KMK version of that, which you can find linked on the front page of http://kmkfw.io/


Tbh I found the KMK documentation way more useful than the QMK regarding the 2040 specifically. I have absolutely no problem with defining the keymaps in the file and save it, way more prefer that over that re-compiling everytime. Now with QMK VIA(L) is a must have, because I cant get access to the serial USB to re-flash the MCU. With the RP2040 that shouldn’t be an issue anymore.

I did see the PEG option today, the possibilities to customize the OLED etc. through GUI sound really tempting. Im absolutely hyped about OLED everywhere, but have absolutely no idea how to manage them (to come…)

1 Like

Aaaaand its alive and working :slight_smile: I just have to do some cleanup and split the code in two files, when I will upload it to GitHub. Not really thinking about switching back to QMK right now to be honest…