I’m late to this party but I have a Moonlander (which is QMK based), a Planck EZ (also QMK based), and a UHK (not QMK based, but open nonetheless).
One of the things I like about them is setting up key combos to trigger power activites. (sleep, hibernate, etc.)
It would be great if we could eventually get some mapping software that would allow the creation of such hotkeys.
No rush though, I love the keyboard on this thing!
Unicode characters cannot just be passed to the OS, as far as I recall. Every OS has different input software for Unicode characters, so even if you could encode the Unicode characters on the keyboard itself, it wouldn’t likely be cross-platform unless you did some silly hack. Furthermore, different OSes implement different portions of the Unicode specification at different times, making it remarkably complicated for the keyboard to keep up with each OS’s updates.At the moment, you can actually set up a QMK keyboard to allow entry of Unicode characters by using the appropriate keycode for your OS along with unicode character number.
I am also looking forward to seeing the firmware level key mapping like QMK for the Framework laptop default keyboard. It fits Framework’s philosophy. Seeing the Input Cover Kit - Blank ANSI/ISO on the Marketplace, the blank input cover will be useful for this feature in the future.
Is there any interface exposed currently for remapping? There are some quick modifications I’d like to make, like remapping the AirplaneMode key to something else, that I could try to pull off and document, assuming it’s possible for end-users.
I’m guessing @Kieran_Levin is talking about this EC host command. It’s not very ergonomic, and it has some limitations, but it does make it possible to perform limited key remapping.
One issue is that the function keys are permanently bound to their FN equivalents — if you make any key emit F8, that key will also emit monitor brightness up when FN is off. Same thing if you rebind what the key labeled F8 does: it will lose the ability to control monitor brightness as well.
I have some ideas that would make it possible to fully control FN mapping from within the OS, but I’m wary to commit to doing it because (1) support and (2) I don’t want to step on Kieran’s toes too much. Building too many things on top of the aforementioned document might make it hard for Framework to do new stuff.
Finally a user did change the keyboard layout on the firmware level by using DHowett’s ec tool, and also changed the key caps too. Amazing!
I just found GergoPlex, the compact 36 keys keyboard layout, and the thin (low profile) key-switches and key-caps are repairable and customizable. (The vendor’s website is under maintenance right now.)
This is what I want to see for Framework Laptop’s keyboard in the future. I realized that a thin keyboard is possible with reparability by watching the video. The zip keycaps like ZSA’s one are also useful to reduce the keys by customization. Right now I am practicing with ZSA’s Moonlander’s 36 keys keyboard layout.
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
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.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?
Thanks for the input! All noted.
I believe they connected an existing mechanical keyboard that was already running QMK over USB. 
I appreciate your work! I am looking forward to seeing it!
I see. That makes sense.
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.
I’m not fond of the idea of losing one of the 4 usb ports just to have the keyboard attached.
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.
It seems that a fantastic thing happened. 
- Introducing the Framework Laptop 16 and both Intel and AMD-powered Framework Laptop 13
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.
Just to confirm, that would be in the 16” version only?
I am not sure about it.
Here is the repository of the Input Modules. The Framework Laptop 16 is only mentioned there.
I believe this is correct, yes. The new generation of Framework Laptop 13 uses the same input covers as the previous two generations.
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.