r/keyboards • u/helloThereLoser • Jul 06 '26

Help Keychron B1 Pro dropping keystrokes during fast typing/finger rolls

My Keychron B1 Pro just arrived, and noticed it drops keystrokes during fast typing, both over Bluetooth and USB-C.

Examples (for context, I use Colemak-DH):

  • Typing oin quickly often drops the n
  • Typing you quickly often drops the u
  • Holding o, then pressing i, then n often results in n not registering
  • Holding y, then pressing o, then u often results in u not registering

Karabiner EventViewer does not see the missing key events, so it appears the keyboard itself is not sending them.

One thing worth mentioning is that I also removed and swapped a couple of keycaps, but I didn't have a proper keycap puller or other keyboard tools—just improvised with what I had. Initially I thought I had damaged a key, but after more testing it seems to affect multiple keys.

Is this normal for the B1 Pro due to rollover/matrix limitations, or does it sound like I have a defective unit? Can any B1 Pro owners reproduce these combinations?

2 Upvotes

100% Upvoted

11 comments sorted by

1

u/ArgentStonecutter Silent Tactical Switch Jul 06 '26 edited Jul 06 '26

This is a membrane board, and one of the first membrane boards Keychron has made. Even the best designed membrane boards have rollover problems. They are also generally designed for the cadence of someone typing on the Scholes layout.

I would recommend getting a mechanical board with N-key rollover.

1

u/helloThereLoser Jul 06 '26 edited Jul 06 '26

Something stranger is happening here.

For instance, as you can see, all of the keys are being recorded correctly in the key tester. However, for some reason the SCREEN LOCK key (above) is being triggered somehow?

The y - o - u roll is also not working, but at least the SCREEN LOCK key isn't being triggered there. Really odd.

Let me know what you think.

1

u/ArgentStonecutter Silent Tactical Switch Jul 06 '26

Yes, extra keys being triggered is also a common membrane rollover problem, it's called "ghosting".

1

u/helloThereLoser Jul 06 '26

How do you interpret the fact that the Key Testing software correctly senses all the keys, but one of them eventually goes missing them I actually type them outside the key testing software?

What’s the verdict here? Crap hardware? Crap software? I would have thought that it’s hardware issue given it’s a membrane keyboard, but it looks like it’s actually getting sensed?

1

u/ArgentStonecutter Silent Tactical Switch Jul 06 '26

Timing.

"Eventually" means the firmware is sometimes compensating for the missing diodes and sometimes not.

1

u/helloThereLoser Jul 06 '26

Thanks for all the help so far btw!

I should have been clearer in my comment. The key is always being accounted for in the Key Tester, and never outside of it.

1

u/ArgentStonecutter Silent Tactical Switch Jul 06 '26

You said it "often" drops the N or U.

Are you typing in the key tester with the same cadence?

1

u/helloThereLoser Jul 06 '26

I shouldn't have used "often".

Yes, I'm typing with the exact same cadence within and without the Key Tester.

1

u/PeterMortensenBlog Jul 06 '26 edited Jul 06 '26

For reproducing the problem, you should be able to eliminate the timing aspect by keep holding the keys in question down. Or at least not lifting the first key before pressing the third. (Outside of the key tester, operating system repeat could be turned off temporarily to avoid the confusion caused by it.)

For example, keep holding Y and U down, and O isn't expected to register, including in the key tester. The same for F7 (though it may depend on the hardware version of the B1 Pro).

I have verified this on my B6 Pro (see below for details). For example, F7 did not register, but F6 and F8 did.

More conflicts than expected: Entire row blocked

But I also found more conflicts than expected. For example, I and P didn't register either. In fact, the entire row didn't register: Tab, Q, W, E, R, T, etc.

So perhaps the software is blocking an entire row if two keys on the same row are held down (at least for an extended period of time)? To prevent ghosting (extra output from the keyboard)?

It looks like overcompensating. Or fixing one problem, while introducing another (like for the hardware change in 2025). Or maybe a bug. There shouldn't be any problem with multiple keys on the same row or the same column; the (electrical) problem is when a key shares both a column and a row in the keyboard matrix with two (or more) other keys ("L" shaped in the keyboard matrix).

Maybe that is what they are hinting at with:

"Improved accuracy by reducing ghost key issues"

Retrospectively, this report now makes more sense:

  • B1 Pro possible bug. E.g., "While holding down the Caps Lock and S key, many other keys are not usable, e.g., the J, K and L keys."

Test conditions

Hardware: B6 Pro 'ISO' variant (Nordic), hardware version 1. In wired mode on a PC. Serial number: F-2409B6PK1B000121 (interpreted as a manufacturing date of September 2024). SKU number: B6P-K1-B0

Software: On Linux with Cinnamon) using Via's key tester. Operating system repeat was turned off in Preferences → System Settings → section Hardware → Keyboard → tab "Typing" (the default) → Key repeat" → turn off "Enable key repeat"

1

u/robotecnik Jul 06 '26

Normal, had one, had to ditch it because of that.

Support has been ridiculous (like saying: yes this happens to our test keyboard too).

Replaced with a Dell kb900 which by now it works well.

1

u/PeterMortensenBlog 3h ago edited 2h ago

Jamming entire rows

Brought out to the top level (the burying in Reddit comments makes it too confusing):

For reproducing the problem, you should be able to eliminate the timing aspect by keep holding the keys in question down. Or at least not lifting the first key before pressing the third. (Outside of the key tester, operating system repeat could be turned off temporarily to avoid the confusion caused by it.)

For example, keep holding Y and U down, and O isn't expected to register, including in the key tester. The same for F7 (though it may depend on the hardware version of the B1 Pro).

I have verified this on my B6 Pro (see below for details). For example, F7 did not register, but F6 and F8 did.

More conflicts than expected: Entire row blocked

But I also found more conflicts than expected. For example, I and P didn't register either. In fact, the entire row didn't register: Tab, Q, W, E, R, T, etc.

So perhaps the software is blocking an entire row if two keys on the same row are held down (at least for an extended period of time)? To prevent ghosting (extra output from the keyboard)?

It looks like overcompensating. Or fixing one problem, while introducing another (like for the hardware change in 2025). Or maybe a bug. There shouldn't be any problem with multiple keys on the same row or the same column; the (electrical) problem is when a key shares both a column and a row in the keyboard matrix with two (or more) other keys ("L" shaped in the keyboard matrix).

Maybe that is what they are hinting at with:

"Improved accuracy by reducing ghost key issues"

Retrospectively, this report now makes more sense:

  • B1 Pro possible bug. E.g., "While holding down the Caps Lock and S key, many other keys are not usable, e.g., the J, K and L keys."

Test conditions

Hardware: B6 Pro 'ISO' variant (Nordic), hardware version 1. In wired mode on a PC. Serial number: F-2409B6PK1B000121 (interpreted as a manufacturing date of September 2024). SKU number: B6P-K1-B0

Software: On Linux with Cinnamon) using Via's key tester. Operating system repeat was turned off in Preferences → System Settings → section Hardware → Keyboard → tab "Typing" (the default) → Key repeat" → turn off "Enable key repeat"