As title says, noticeable most in games. Does not happen with a dedicated keyboard, only with the 12’s membrane keyboard which leads me to believe it’s an issue with that.
The physical key signal matrix cannot handle certain combinations of keys all pressed at once because there aren’t enough “pathways” for all of them to flow at once. What you are looking for is an “NKRO” external keyboard which can report all keys’ pressed status independently of the rest of the keyboard. Or if you have the know-how you might be able to make one for the FW12’s input cover slot, I dunno for sure about that though.
The Framework 12 keyboard isn’t very good and has some problem with key rollover. It’s not really a defect, it’s kinda by design.
Did we ever get an official statement that it is actually a limitation of the matrix and not just overly trigger happy anti-ghosting? Naively I would have expected them to reuse the matrix of the fw13 which I am fairly sure can do that.
Hi had contact with support about the “issue” I got told they will update something on the git page and will tell me what’s now the cause of it. I never got a answer from them, but have to be honest I didn’t ask again either. I had contact 2 or 3 months back i guess.
maybe they can post a statement here. would be helpful for all of us.
@Eagle could you dive us some more info about the topic.
thx. ![]()
This is interesting.
The protocol used over usb to a keyboard is normally a bitmap.
I.e. with every key press, the entire bit map, of every key state is reported.
The OS then processes this and outputs the appropriate key events.
I find it difficult to understand how this would cause problems with particular key combinations.
I only have a FW16, so cannot test this FW12 problem.
These tests only work in Linux. They do not work on Windows.
I just tested, on a FW16 keyboard, shift+w then space bar. And the output from /dev/input/event9 is as expected. The correct key down/up events are reported.
The test I did was this on Linux:
apt-get install evtest
evtest /dev/input/event9
The “event9” might be a different number on the FW12, but it would be interesting to see the output of evtest on the FW12, if you could post it here.
E.g. For my FW16 it is:
Event: time 1765631097.677495, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70028
Event: time 1765631097.677495, type 1 (EV_KEY), code 28 (KEY_ENTER), value 0
Event: time 1765631097.677495, -------------- SYN_REPORT ------------
Event: time 1765631101.322273, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e1
Event: time 1765631101.322273, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 1
Event: time 1765631101.322273, -------------- SYN_REPORT ------------
Event: time 1765631101.545267, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7001a
Event: time 1765631101.545267, type 1 (EV_KEY), code 17 (KEY_W), value 1
Event: time 1765631101.545267, -------------- SYN_REPORT ------------
Event: time 1765631101.819981, type 1 (EV_KEY), code 17 (KEY_W), value 2
Event: time 1765631101.819981, -------------- SYN_REPORT ------------
Event: time 1765631101.859717, type 1 (EV_KEY), code 17 (KEY_W), value 2
Event: time 1765631101.859717, -------------- SYN_REPORT ------------
Event: time 1765631101.899652, type 1 (EV_KEY), code 17 (KEY_W), value 2
Event: time 1765631101.899652, -------------- SYN_REPORT ------------
Event: time 1765631101.939528, type 1 (EV_KEY), code 17 (KEY_W), value 2
Event: time 1765631101.939528, -------------- SYN_REPORT ------------
Event: time 1765631101.979736, type 1 (EV_KEY), code 17 (KEY_W), value 2
Event: time 1765631101.979736, -------------- SYN_REPORT ------------
Event: time 1765631102.019706, type 1 (EV_KEY), code 17 (KEY_W), value 2
Event: time 1765631102.019706, -------------- SYN_REPORT ------------
Event: time 1765631102.035013, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7002c
Event: time 1765631102.035013, type 1 (EV_KEY), code 57 (KEY_SPACE), value 1
Event: time 1765631102.035013, -------------- SYN_REPORT ------------
Event: time 1765631102.094705, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7002c
Event: time 1765631102.094705, type 1 (EV_KEY), code 57 (KEY_SPACE), value 0
Event: time 1765631102.094705, -------------- SYN_REPORT ------------
Event: time 1765631103.960821, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7001a
Event: time 1765631103.960821, type 1 (EV_KEY), code 17 (KEY_W), value 0
Event: time 1765631103.960821, -------------- SYN_REPORT ------------
Event: time 1765631104.343971, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e1
Event: time 1765631104.343971, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 0
Event: time 1765631104.343971, -------------- SYN_REPORT ------------
Hi you got some info how I can test it like you did.
I know some things regardig pc tech but thats a bit new to me.
BR
Hey @LukiG Sorry for the delay. Not sure why the ping didn’t go through correctly. Are you still needing me?
Hi, yes. It would be nice to understand why some key-combinations don’t work. Especially the w+shift+space combination.
Is it a hardware limitation or is it something that can be fixed with software updates.
KR Lukas
Hi @LukiG The Framework 12 doesn’t currently support NKRO. The EC firmware is open source, so you can see the full keyboard implementation on our github. Hope this helps answer your question!
Hi thanks for the fast reply, but have to be honest that my understanding for this tech isn’t that deep. For me and I guess for others it would be nice to know if the issue is a hardware one which can’t be fixed except with a new input cover version or if it’s a software issue that may be fixed with a future update.
Thx and br
To do the same test, all you need is a install of Linux, or a LiveCD with linux on it and the “evtest” application installed.
To understand the output.
value 0 == key released
value 1 == key pressed
value 2 == key held down (this can be mostly ignored).
As long as the keyboard can correctly do the value 0 and value 1 output for the various key combination, the keyboard hardware is fine, and it is just a matter of software to fix any bugs.
So, the above evtest on a FW 16 I did has:
KEY_ENTER, value 0 (I release the ENTER key while typing evtest command)
KEY_LEFTSHIFT, value 1 (I pressed the left shift key)
KEY_W, value 1 (I pressed the “w” key)
KEY_SPACE, value 1 (I pressed the SPACE key)
KEY_SPACE, value 0 (I released the SPACE key)
KEY_W, value 0 (I released the “w” key)
KEY_LEFTSHIFT, value 0 (I released the LEFT SHIFT key).
So, it detects all the key events, no matter what order I do them, and how many I hold pressed.
If you do a similar test on a FW 12, you will see if it is a hardware problem or a software problem.
If you are playing games, features like N-key rollover don’t matter, and it just looks for Press, Release events, because games expect multiple keys to be pressed at the same time.
So then I think most of us are wondering why this isnt higher priority? It’s a pretty basic feature and I cant remember the last time i had a keyboard with an issue like this, especially a laptop keyboard. Gaming is extremely popular and most people play games even if not often. It’s pretty infuriating when using the laptop on its own. Obviously you can have another keyboard but that is not convenient for a laptop.
if the lack of NKRO is in the EC, does that mean all framework laptops do not support NKRO? or is there a limitation in the Framework 12 hardware itself?
Hm, a bit of confusion around.
So far, each Framework has been very different in how it implements its keyboard. Can’t assume anything will transfer over to other model. Only the FWL13 has a key matrix directly connected to the EC (there the EC acts as keyboard controller, in addition to its other tasks). FWL12 has a keyboard controller chip between the matrix and the EC, connected to the EC via i2c. And the FWL16 keyboards are actually fully independent usb keyboards, with a rp4020 as keyboard controller running qmk.
I don’t pay much attention to NKRO since I don’t do much gaming that needs it. I think it’s just not common in laptop keyboards. Instead, I think manufacturers just try to make a key matrix that avoids conflicts with likely key combos.
It sounds like you might be misunderstanding where key rollover issues take place? It’s between the keyboard matrix and the keyboard controller. Linux, windows, any OS, won’t be able to tell the rollover issues are happening. Since it’s on an altogether lower level.
While we don’t know for sure this is a pure key rollover issue, that seems to be the assumption everyone is going with at the moment, no?
The FWL16 and 12 also differ in how the keyboard is connected, the 12 doesn’t use qmk over usb. But that doesn’t make a difference as far as potential key rollover issues.
I haven’t looked at the FWL12 EC code, but key matrix decoding shouldn’t take place on the mainboard EC.
On the 12 there is a ITE tech chip between the keyboard matrix and the mainboard EC. And the input cover pinout doesn’t carry the keyboard matrix over to the mainboard. Instead, it has i2c. So it seems the ITE chip is the keyboard controller here. Maybe it’s firmware is also open source?
Yeah that one would be the culprit if they have not just made some very unfortunate choices when designing the matrix. The other question is if that can even take firmware updates. I kind of hope that thing has some firmware and isn’t some form of fixed asic.
@Eagle Could you find out if the fw12 keyboard uses the same matrix as the 13 (or could you get us the matrix itself it it isn’t the same).
There are different ways to implement anti ghosting and some of them are a bit overly trigger happy, especially in cases where the matrix has holes (you can for example have an ambiguous key press but only one of the options exists so you can let it through or just blindly ignore it because it is ambiguous).
There is a solid chance the matrix is the same as in the 13 as they likely used the same manufacturer and I don’t really see much reason why they would not have copy pasted as much as they could.
Hi @Adrian_Joachim Are you looking for this FW12 Keyboard Matrix?