So, in my spare time I have been working on exactly¹ this². It’s been my daily driver for the past few months, and it seems to work great.
I’ve got one really big question though:
What does “QMK configurable” mean to you?
QMK is primarily a source code distribution, with hand-written and hand-tuned keyboard layouts developed in C. Consider nikchi’s frosty_flake customization, which is by no means unique in the qmk_firmware repository.
There are some graphical tools (open-source ones like config.qmk.fm and proprietary ones like ZSA’s Oryx), but each one of them produces a full flashable firmware image for your keyboard.
Since the keyboard on the Framework Laptop is controlled by the embedded controller, offering web-built full flash download seems very risky. The keyboard part of the firmware isn’t isolated and can’t be reflashed separately, so every time you change your keyboard layout you’re risking wearing out the flash or being left with an unbootable machine… and every keyboard layout change requires a full reboot of the laptop.
I have some thoughts (which I’m happy to go into) about how to proceed but before I do I’d love your take. What does it mean to you?
¹ It’s all in a branch of my fork of Framework’s EC code here, for those of you intrepid enough to try it.
² It has also been pulled out into its own separate repository.
³ The “stock” keymap represented in my fork is here; note how it resembles a QMK keymap.c.
You are using a firmware-level customized keyboard layout by the QMK-like file. Cool project!
My expectations are
There is one default keymap file that is equivalent to the Framework’s ANSI layout on the qmk_firmware repository. I think we don’t need to manage user-level keymap files such as “nikchi’s frosty_flake customization” on the repository.
Users can create their own keymap file from the default keymap file by a tool such as “config.qmk.fm” or other tools.
Users can flash “a” firmware from their customized keymap by a tool.
Someone provides other keyboards (hardware or CAD file) with replaceable keyswitches and keycaps, and the keyboard layout like Moonlander’s one. Then users can replace each key.
I see. Hmm. This is risky. But how did the framdeck, the Framework’s mainboard-based cyberdeck achieve the 36 keys’ keyboard layout? Seeing this issue ticket, QMK is used?
I just got one idea to use keyboard QMK on the Framework Laptop. Can you imagine? In this way, people can use the independent keyboard firmware.
Use one of the 4 USB-C ports used for the expansion cards to connect the internal keyboard.
One expansion card is to connect the internal USB-C with the internal keyboard inside the board. There is not interface to connect outside. So, the internal keyboard works like existing mechanical keyboard.
I can understand it. So, perhaps a better idea for the expansion card is IN: one internal USB-C port connects with the mainboard’s USB-C port, OUT: 2 USB-C ports (one connects with the internal keyboard, another is used as the external USB-C interface). The expansion card behaves like a USB hub.
We’ve also released open source firmware based on QMK keyboard software that runs on the Raspberry Pi RP2040 microcontroller that many of our Input Modules utilize.
With an open source design, we can’t wait to see the incredible modules that the community creates: jog wheels, sliders, touchscreen displays, e-ink notepads, smartcard readers, and more. Really, almost anything can be created into an Input Module. The only limit is your imagination, and the 3.7mm height constraints.
It does, but interestingly, the width and length of the large input module appears to be almost exactly the same as the Framework 13 keyboard. It may be that height would be a problem, but I wonder if a different input cover design would allow a large input module to be used on the Framework 13.
As the keyboards will be the same in terms of key structure, though, I wonder if more invasive solutions (a specific, different input cover for a specific keyboard) might work.
That is a shame. I think the 13” model with programmable Atreus keyboard would be the ultimate portable writer’s notebook. The 16” might be a bit overkill for my needs but hard to turn down if it offers ergonomic keyboard modules.
In the other hand Framework might decide to offer a revised 13” chassis in a couple of years whilst taking the opportunity of bringing the best of what they learned designing the 16” model back onto the smaller format. That would surely include the programmable keyboard modules.
Using the same software as the QMK firmware, the 16" keyboard should have an N-key rollover function. This means every key has a diode to prevent ghosting. a Different key matrix or circuit than the 13" keyboard and connector of key membrane sheet and main board are different.
Then, the 13" keyboard will not have QMK.
I don’t think so. Haven’t seen Framework mention plans to add qmk to the 13". It’s not something they can do in just software. If they did it, you would need a new input cover assembly. Since they would need to add a chip that supports qmk.
I’d buy one if they made it… 100%.
Where can I upvote this request…
Also it’s gotta be ortholinear… Its about time we abandoned the typewriter style staggered key nonsense.
I love my 13 and use qmk and zmk on all my custom boards… I end up doing this most of the time as my preffered board is wireless and split
- 