
Myths about USB NKRO and how USB HID works - panic
https://www.devever.net/~hl/usbnkro
======
praseodym
> Yes, this means you could theoretically make an analog keyboard which
> reports the level of key depression.

There is at least one company making analog keyboards, mainly for gaming:
[https://wooting.io/](https://wooting.io/)

~~~
DavidVoid
The Realforce 108UH-ANLG [1] can also do that and can even emulate the analog
sticks and buttons used on gaming controllers. Here's a demo video of one
being used as a piano [2]. You can tell that harder keypresses result in
louder notes. I don't think it's been released outside of Japan yet but they
have some keyboards with customizable actuation points using the same Topre
switches [3].

[1] [https://www.realforce.co.jp/products/108UH-
ANLG_AFAX01/index...](https://www.realforce.co.jp/products/108UH-
ANLG_AFAX01/index.html)

[2] [https://www.youtube.com/watch?v=mhCSIy-
Qt0M](https://www.youtube.com/watch?v=mhCSIy-Qt0M)

[3]
[https://www.realforce.co.jp/en/products/R2A-US4G-BK/index.ht...](https://www.realforce.co.jp/en/products/R2A-US4G-BK/index.html)

~~~
m463
The Steelseries Apex Pro has keys that can detect depth, but they too use it
for actuation points. They keys are omnipoint.

I really (really) like my topre realforce rgb although the apex pro is very
close in terms of solid feel, and has much more interesting electronics.

------
gruez
AFAIK most USB keyboards with nkro implement it by emulating multiple USB
keyboards, which I guess is also within the hid spec? The manufacturers
probably figured that approach was more reliable than using one hid device
with a custom reporting format.

~~~
p_l
It's cheaper to reuse the same USB 1.0 controller chip than update. That's it,
the dirty secret.

Some keyboards also do that to support OSes that have broken HID drivers, like
Mac.

~~~
rasz
No, and it makes no sense. There are no fixed function USB HID controller
chips. They are all microcontrollers with USB interface. Makes no difference
from chip point of view if it reports being basic HID profile or a custom one.
Besides you can even bitbang being 10 hid devices on a good old Arduino.

~~~
p_l
A cent here and there on manufacturing several hundred thousand units quickly
adds up. And that's just the MCU used.

The cost of replacing the MCU with something that can run USB1.1 instead of
1.0, cost of programming, cost of dealing with broken cases that don't support
HID properly (for example BIOSes that don't send "boot proto only" command, or
every Mac) quickly increase the total cost. And the margins are thin.

And then there's the fact that even people who should know better often
believe myths about USB being unable to report more than 6 keys - even if they
are keyboard vendors who should know better and are making a high-enough
margin to use better controller.

~~~
rasz
>cent here and there

someone counting cents will not use several microcontrollers + separate usb
hub chip, where did you get that idea from anyway?

>cost of replacing the MCU with something that can run USB1.1 instead of 1.0

[http://www.os2museum.com/wp/how-fast-again/](http://www.os2museum.com/wp/how-
fast-again/) there is no hardware difference between 1.0 and 1.1.

~~~
p_l
What I found was that in Low Speed mode, the maximum packet size made it
impractical to use anything but the Boot Protocol.

As for counting cents - for majority of keyboards made, you'll get as little
work done on the keyboard controller as possible. If they add a separate USB
chip, it's usually logically separate from the keyboard anyway.

When you reach the more fancy keyboards, you deal with another problem.

Namely, what to do with all the broken software involved. Your priority for
reducing costs is removing support calls, angry gamers calling when they can't
change their overclocking parameters in BIOS, Macintosh users complaining the
keyboard doesn't work at all, corporate/OEM clients returning keyboards
because it is not possible to input password to _McBuggy Disk Encryption and
Employee Spyware v6.66_ when the computer starts.

Those limit your options when the budget for your fancy keyboard would provide
for better microcontroller.

------
coretx
The cheap Chinese keyboard I have over here emulates NKRO by simply reporting
5 different keyboards. Although the idea makes me cringe from a engineering
pov I've to admit it works really well.

------
guerby
I wonder if USB HID compliant keyboard can report their key map (like QWERTY
vs AZERTY)? If yes is there some OS taking advantage of it and how?

In 2020 keyboard mapping is still a mess IMHO but may be I'm missing something
:)

~~~
JdeBP
You're missing the fact that keyboards _do not have_ key maps to report. The
wire protocol and the device do not remap keys. It's all done in software on
the host.

* [https://news.ycombinator.com/item?id=22207431](https://news.ycombinator.com/item?id=22207431)

~~~
jcrawfordor
I think the GP's idea is that a keyboard could report to the host _how its
keys are labeled_ so that the host could automatically select the correct
keymap. This is indeed a very cool idea, but would certainly be a big effort
to get implemented across all platforms.

This would be somewhat similar the more boutique input devices which are
configurable in hardware.

~~~
JdeBP
That is not the keyboard map. It's the engraving, which has _zero effect_ on
the keyboard, neither electrical nor mechanical. Keyboards can be re-labelled
with little bits of paper and sticky tape or by swapping keytops, and that
does nothing. _There is no keyboard map_ here.

~~~
comex
Of course keyboards can be relabeled. But they usually aren't. If,
hypothetically, keyboards came with knowledge of their original labeling, that
would be meaningful information. If computers used it to set a default key
layout, that would make for a better default _if_ the goal is to make key
behavior match the labeling. It would fail to match the labeling if you
changed the labeling, but it would still be accurate much more often than the
current default.

That said, I question whether most people actually want key behavior to match
the labeling. I think any touch typist would rather use their preferred layout
regardless of labeling.

~~~
jcrawfordor
As a recovering Dvorak user, I would very much like the match-the-legends
behavior, because for quite a long time I used a keymap which was not the
default. At one job I had an Advantage2 that I carried around with me because
the keys were internally remapped (when you pressed a key it reported the
scancode for that letter on QWERTY) because of how time consuming it is to add
a keyboard layout in most operating systems. Unfortunately that kind of
internal remapping is mostly only found in some very expensive keyboards.
There's at least one vendor that sells a USB dongle that does the same
remapping to a pass-through USB keyboard for the same reason.

This problem would be infrequently encountered in the US (mostly just Dvorak
and Colemak addicts) but is a lot more common in Europe due to AZERTY.

------
ploxiln
The trick to get not-exactly-standard BIOS and OS working (with NKRO for the
OS) is not at all obvious ... I first read about it in
[https://static.wongcornall.com/ibm-capsense-usb-web/ibm-
caps...](https://static.wongcornall.com/ibm-capsense-usb-web/ibm-capsense-
usb.html#x1-160003.3.2)

------
SlowRobotAhead
Pretty clever trick using the padding to get the boot info there for
compatibility.

------
janci
If I remember correctly, the good old PS/2 keyboards used to send "key down"
and "key up" events - so no limit on number of simultaneous keypresses. Why
was this not reflected in USB HID?

~~~
simias
My guess is that the problem with sending events is that if you miss one
you're in trouble (in this case it's especially bad if you miss/lose the "key
up" message). Given the potential complexity of USB topologies making the
protocol stateful might have caused more problem than it would've solved.

Besides is there any use for NKRO besides being a meme feature for overpriced
keyboards? The only use case I can think of is if you play two player games on
the same keyboard but doesn't seem very common these days (and you can
probably buy a decent gamepad for the price of a NKRO keyboard).

~~~
derefr
Would it be that expensive to put ~4K of RAM in the keyboard’s microcontroller
to act as an event queue? Write keydowns/keyups into the buffer; then push (or
respond to a poll with) the complete contents of the buffer as a single USB
packet; and flush the buffer on ACK. (I presume USB does ACKs?) 4K would be
more than enough to buffer all possible key events a pair of human hands could
create in a reasonable polling interval (~16ms, i.e. 1 frame for a 60Hz game.)

Add a clock chip to the HID device as well, and you could even get finer
event-reporting granularity than the OS cares to poll for (i.e. the buffer
delivered at (Polling Interval x N)ms, would contain events timestamped for
(Interval x (N-1)) ms, (Interval x (N-1) + 1)ms, etc.) The timestamps could
just be relative to the beginning of the interval, so they wouldn’t need to
take up that many bits at all.

~~~
magicalhippo
> then push (or respond to a poll with) the complete contents of the buffer as
> a single USB packet; and flush the buffer on ACK

Two issues. Unless you use USB 2.0 high speed, USB "packets" (transactions)
are small[1]. For low speed they can have 8 bytes of data, full speed 64
bytes. USB 2.0 HS is a lot more costly of course.

Secondly, keycodes that are sent in the same report have no defined order[2].
Thus if two keys were not present in previous report and are present in
current report, the order in which those two keys are pressed are
indeterminate to the OS.

So that would not be very helpful I think.

[1]:
[http://www.usbmadesimple.co.uk/ums_3.htm](http://www.usbmadesimple.co.uk/ums_3.htm)
(Interrupt Transfers)

[2]: [https://www.usb.org/document-library/device-class-
definition...](https://www.usb.org/document-library/device-class-definition-
hid-111) (Appendix C)

------
colejohnson66
I’ve noticed this on my keyboard. It has a “BIOS mode”, but it works fine in
“regular mode” in the BIOS anyways. Maybe because it’s actually UEFI?

~~~
p_l
It means that either your firmware has more complete HID driver (doubtful) or,
or likely, it properly sends "switch to boot proto" command.

------
lejboua
Today I learned. Thanks for this!

------
ScarZy
This is my kind of post. Respect.

