First of all thanks for setting the bar for other companies. I hope everything you do will come together just right!
Currently I have a whole another laptop that is not framework and I have an external TKL keyboard which I configured using QMK.
I was looking through the QMK firmware that you write for framework and I understood that you’ll probably end up having the main keyboard and keypad as two separate keyboards plugged in through separate USB lanes.
Then it occurred to me that I have a mapping of my own FN layer and I have some keys mapped to the part where you’d be having a keypad. But if it’s two separate keyboards then it wouldn’t be possible on the keyboard level. Also solutions like KMonad would also not work.
Is there a way to not have these issues if I’d be using the main keyboard with some kind of key panel? Let’s say I’ll buy the numpad panel and I’ll try to work with it (or maybe you’ll also have TKL keyboard and I’ll want to make the 9 keys into a number pad (this is what I have in my TKL keyboard)).
(also will you have options for TKL or ANSI without FN key (if it’s QMK-configurable then some users would probably configure it without that key)?)
I don’t understand what you are saying, and what is your concern.
You meant that the two separated keyboards are problem to have another layer?
I have the external split keyboard called Moonlander running with the QMK. And the left and right keyboard PCB are connected with a cable from the both controllers. I haven’t openned the Moonlander. So, having the 2 controllers are my assumption.
And here is my current 34 keys layout. You see the “1 hold” key on the left bottom. The key changes the layer from layer 0 to layer 1 when holding the key. It’s like Fn key on teh current Framework Laptop. The key uses the feature of “MO (layer)”.
MO(layer) - momentarily activates layer. As soon as you let go of the key, the layer is deactivated.
And I am also assembling another external split keyboard called Sweep Bling LP now. The keyboard has 2 controllers (in my case, the RP2040 based controllers to run QMK on it). This picture on QMK repository shows the 2 controllers on the both PCBs.
Sorry if I didn’t make it clear that I talk about FW16 laptop and not QMK boards in general. I know that modular boards exist and they work. But my point was that the preview video of FW16 doesn’t have that jumper cable between keyboard components.
If the boards connect at the top then it means they don’t connect through each other.
So that means that they can’t interact with each other and influence each other’s layers.
From what I understand they’ll all connect directly via USB to the laptop and not to each other. That means that you won’t have ability to have layered bindings between keybaords without a bridging software in the laptop itself.
From what I understand the keypad is going to be a whole another keyboard.
Maybe you can have a keyboard that connects to the laptop using one cable (or bluetooth connection) but then they have to connect to each other.
For instance if they can put the keypad on the left then they would need the keyboards to have two additional connectors on the side which I didn’t see in the specification.
Your picture shows that the keyboard parts connect to each other and only one cable connects to the laptop which means that the laptop sees it as one keyboard and not two.
Of course – maybe they’ll have a jumper cable that will connect both keyboard parts but who knows because there are no specs yet. The only specs that are released are for the keyboards that connect at the top.
The introduction of the 16" states that the options for the 16" input module system are not only the numeric keypad, but also the secondary display, macropads or haptic sliders.
I guess this means that the numeric keypad is not connected to the keyboard.
But also the introduction states, “We’ve also released open source firmware based on QMK keyboard software” so maybe this new firmware. And 16" will recognize and configure keyboard and numpad as whole one keyboard.
I do not have the skill to read the new QMK keyboard software program at Github. If you understood it, maybe possible to see how 16" looks keyboard and numpad.
This file shows the configuration of the main keyboard. This main keyboard only has main part keys. This keyboard would be called “65% keyboard” or similar (100% is what the full size one with numpad is called).
I don’t know how lotus branch is different from development though. And why they decided to have it. Maybe it’s their master/main branch. Maybe it’s the keyboard name.
Maybe it’s somehow possible to connect those two keyboards together (directly to each other) but from what I see the given QMK firmware doesn’t have this mode of operation.
It’s simpler to do it and I would also do it the simpler way first as there are harder challenges to come through. But I only wanted to make sure if this is not their goal to connect these two keebs together.
Also maybe there is a way to connect them. Then we could talk about it in this thread (but I mainly wanted to know whether this is the intended design).
Imagine you have two keyboards that are running QMK as their operating system. They don’t know about each other and layers only exist in their memories. So if I press FN or other layer enable button that doesn’t immediately send the info to the PC because it still expects that you press something else. And then it won’t change the action of the second keyboard.
Of course if the key is Shift then it will be sent to the PC immediately and you’ll get capitalization in the second keyboard keypress. So Shift key and FN key work differently.
So the layer functionality won’t work in two keyboards. For instance you could set up a numpad in your QWEASDZXC keys in both keyboards but you wouldn’t be able to use your FN key to trigger this when you press FN on one keyboard and Q on the other.
Good catch! My experience is only with Moonlander (an external QMK-based keyboard), As far as I know, I am not sure if there is a key mapping to the Compose key. Last year there was not. And I don’t know about Scroll Lock and Num Lock.
However, in the case of compose key, I am binding both Shift+Esc and Shift+Caps Lock as Compose keys. I can type it from the external keyboard Moonlander on the i3 window manager, but cannot type it from the external keyboard Moonlander on the Wayland-based window manager sway. I can type it from the internal keyboard on the both i3 and sway on the Framework Laptop. So, it can be solved by the software side. But I have not reported this issue to the sway project yet.
This issue on the sway happens not only with a QMK-based keyboard specific but also with a USB external keyboard without QMK.
There are a couple ways layer states can be communicated between QMK devices.
The simplest is for layers that have associated led indicators defined in the HID spec (Num Lock, Caps Lock, Scroll Lock, Compose and Kana). qmk feature_led_indicators. Any time the state of one of those keys changes, all usb connected keyboards receives notice. I’ve used this method to trigger layer changes and it happens virtually instantaneous. Scroll lock is convenient for this since the key has become unused. Scroll_Lock Other_uses. You can also program a qmk device to change layers only when an led indicator is toggled very quickly, faster than a human can tap.
Qmk also has the Raw HID feature which allows for bidirectional communication between qmk and the computer. I haven’t explored this myself, it would probably require the computer to actively relay messages between qmk input modules.
So if I understand correctly the USB-based QMK keyboard will be able to broadcast what layer it’s in?
And then… other device could capture this broadcast?
The sources that you’ve linked show that the handlers are kind-of hardcoded based on whether it’s the traditional modes.
Do you think it can work if I’d configure L1, L2, L3 and other layers that aren’t connected to numlock or other layers?
This would probably mean that the firmwares for each additional keyboard would need to be aligned to handle each other’s broadcasts but I hope I won’t need to hardcode every mode handler into every additional USB component.
I presume you mean the led_indicators feature, the reason that it only covers those layers (Num Lock, Caps Lock, Scroll Lock, Compose and Kana) is that it uses a basic function of the USB protocol for keyboards and other input devices (USB HID). USB human interface device class - Wikipedia
Keyboards and mice “just work” when plugged into any computer (or even tablet or phone) without installing any driver because they use the standard usb HID spec and computers have drivers for it built-in.
You might have seen keyboards or mice that have extra features like programmable keys, macros, lights, vibrations even, but those devices all require a driver from the manufacturer to be installed to change / control the extra features.
We don’t know yet what functions Framework will put into their keyboard and numpad. But qmk has a significant community and active developers, if Framework doesn’t include a way for the numpad to respond to extra user-added layers set by the keyboard (and vice versa) I’d be surprised if the community doesn’t add that. What I was saying in my previous post was that there are a couple ways to accomplish it currently in qmk.
Speaking about the qmk community and developers, I noticed this pull request showing at least one qmk maintainer is interested in the Framework 16.
Ok. We’ll see. I’m not deep into QMK but I simply thought about this FN key multi-layer issue. That’s it. For now this is a non-issue but I think that it will be once complicated layouts would need to be implemented.