Questions about NKRO and USB

[Panp858]

Hi guys!
As you can properly see, I’m new to this board (and the technique behind keyboards too). I read a lot of threads and posts in this forum to answer the question myself, but I’m stuck at too many points.
Before I came here I thought that 6KRO is the limit for all USB-Keyboards and real NKRO is only possible with PS/2 because that’s what you read all over the Internet.

After reading a lot of threads I came to the opinion that real NKRO (not the dirty tricks with multiple virtual keyboards) is possible on USB today. What I don’t understand is how this problem has been solved.

So the questions I’ve in mind at the moment are:
Besides HW limitations e.g. controller or key wiring the USB mode (low speed, full speed) is the real reason why NKRO wasn’t possible in the past, right? With full speed you’ve 1023 Byte data packets for the payload which means, that you can send a status of each key easily. With low speed the data packets are limited to 8 Byte, which mean that you can have a 64KRO in theory. But why is 1 Byte used for one single key on low speed and why can you send the same information in one bit in full speed mode? Is this a protocol definition? Is a real NKRO only possible on full speed USB 1.1 or 2.0?

My second question is about the polling rate. If a Keyboard has a function to change the polling rate by pressing a key, does that mean that the keyboard has to run in full speed?  I’ve a Keyboard next to me which is capable to change the polling rate from 125 Hz (8ms) up (or down :-) ) to 1000 Hz (1 ms). The highest polling rate for low speed is 10 ms which means 100 Hz but I found lot of sources which said that 8 ms is the lowest rate which means 125 Hz. What’s the secret?
I hope you can help me out with the mess of information.

Thanks a lot.

Peter

[Oobly]

This thread needs input from Soarer, I reckon. He's the resident USB HID guru.

[dorkvader]

Apparantly the USB HID (human interface device) protocol includes a listing for "full speed" USB (2.0). If you use this instead of "hi speed USB) (1.1) then you can get NKRO without any fancy tricks.

Unfortunately it also means it won't work on most BIOSes. So you either have to have a switch you can flip to set it to 6KRO mode for when you get into the BIOS, or you have to do a lot of tricks and stuff to recognize when you're interfacing with a BIOS and auto flip to 6KRO for that. I think soarer does the latter. I've seen some functionality for the former on modern keybaords, so I suspect they do a "non-tricky" NKRO over USB, but I don't have any of them so I can't be sure about that.

Anyway, This sort of comptuer communications protocol stuff is a weak point in my knowlege, It's just how I udnerstand it and it could be wrong. Please keep that in mind. If one of the computer engineers would like to chime in, I am sure they can correct me.

edit: I have been corrected, please see below.

About polling rate: There was an excellent post on that that I will now find and then link.

Edit: Here is the topic> I recommend reading the posts by user "grendel" on this: that guy knows his stuff!
http://geekhack.org/index.php?topic=61607.msg1434531#msg1434531

edit:

This thread needs input from Soarer, I reckon. He's the resident USB HID guru.

Soarer's been gone for the last like 5 months.

[metalliqaz]

I have implemented firmware for NKRO on USB.  I think you've over-analyzed the issue and confused yourself.

USB keyboards use the HID spec.  HID rides on top of USB and defines a set of data structures, protocol, and predefined input lists that can be used to implement just about any type of user input device without requiring special drivers.

Within the USB HID spec are some predefined input types that are strictly controlled on how they can act.  This allows small softwares such as your PC's BIOS to be able to use these input types without much complicated code.  One of them is the BOOT-compatible keyboard.  The BOOT-compatible keyboard must always send 8-byte packets.  These packets only leave room for 6 bytes to contain scancodes.  That's where the 6KRO comes from.

Once you are in windows, though, your device is allowed to redefine its input pattern.  My keyboards redefine their HID template to include a large bitfield (16 bytes) that encodes up to 128 keys, thus allowing NKRO.

[Grendel]

What makes NKRO over USB annoying is that a keyboard report has to be able to carry the state of the whole keyboard. PS/2 only transfers key up/down events and pushes remembering the state to the computer. A full blown USB host stack is fairly complicated to implement, esp. if you try to squeeze it into a BIOS. To mitigate this the USB-IF specified the "boot protocol" for keyboards and mice, allowing BIOS's to read these devices w/ minimal programming. The boot-protocol report of a keyboard has a pre-defined layout, one byte that carries the modifiers as a bitmap, one reserved byte, and six bytes that can carry a key code each, hence 6KRO (+ eight mods.) Unfortunately most keyboard manufacturers kept this format for the regular mode in order to keep their firmware/hardware as simple as possible.

About speeds -- even today most keyboards are USB 1.1 low-speed (1.5Mb/s), only a few made the transition to USB 1.1/2.0 full-speed (12Mb/s) so far. I'm not aware of any board that implements USB 2.0 hi-speed (480Mb/s, a bit overkill for a keyboard anyways ) While it is true that the data payload sizes for a single transfer are 8, 64, and 1024 bytes (low-, full-, and hi-speed) you still can send larger reports via multiple transfers.

As for polling speed -- this is the time interval the USB host is querying a device for data. USB in general is host driven, no device can send any data unless instructed by the host. Devices request a poll interval for each endpoint in their USB descriptors, this can be overridden by the host. For low- and full-speed devices this can be 1-255ms. Windows limits this number to a minimum of 8ms for low-speed devices (!) even if the device requests 1ms. In order for true 1kHz USB polling to work the device has to be full-speed.

Some reference material:

 - USB in a Nutshell
 - USB 2.0 Specification
 - Device Class Definition for HID 1.11 (App. B, C, F)
 - HID Usage Tables (pg. 53)

[Panp858]

Thank you all for your answers.

Apparantly the USB HID (human interface device) protocol includes a listing for "full speed" USB (2.0). If you use this instead of "hi speed USB) (1.1) then you can get NKRO without any fancy tricks.

I'm a bit confused here. Why is NKRO with full speed without any tricks possible but with the nearly same high speed mode not? High speed has 1024 instead of 1023 bytes for payload and is very similar.

I have implemented firmware for NKRO on USB.  I think you've over-analyzed the issue and confused yourself.

Good point! Maybe you're right, but I always want to clear my thoughts a learn as much as possible .

USB keyboards use the HID spec.  HID rides on top of USB and defines a set of data structures, protocol, and predefined input lists that can be used to implement just about any type of user input device without requiring special drivers.

Within the USB HID spec are some predefined input types that are strictly controlled on how they can act.  This allows small softwares such as your PC's BIOS to be able to use these input types without much complicated code.  One of them is the BOOT-compatible keyboard.  The BOOT-compatible keyboard must always send 8-byte packets.  These packets only leave room for 6 bytes to contain scancodes.  That's where the 6KRO comes from.

Ok this is not clear for me. As I read here a lot of times before 13 bytes are enough for a full NKRO on full speed. So why can only 6 keys be decoded with 6 bytes on low speed? Is most of the data overhead or are more information transported withing the 6 bytes?

What makes NKRO over USB annoying is that a keyboard report has to be able to carry the state of the whole keyboard. PS/2 only transfers key up/down events and pushes remembering the state to the computer. A full blown USB host stack is fairly complicated to implement, esp. if you try to squeeze it into a BIOS. To mitigate this the USB-IF specified the "boot protocol" for keyboards and mice, allowing BIOS's to read these devices w/ minimal programming. The boot-protocol report of a keyboard has a pre-defined layout, one byte that carries the modifiers as a bitmap, one reserved byte, and six bytes that can carry a key code each, hence 6KRO (+ eight mods.) Unfortunately most keyboard manufacturers kept this format for the regular mode in order to keep their firmware/hardware as simple as possible.

The same thoughts as above. 1 bit for each key but with low speed you "need" one byte for a key (=6 Keys). Thats a part I dont understand atm.
Can you tell me what problems in the BIOS can occur when you use a USB full NKRO has a crappy firmware and you use e.g. more then six keys at one time (or other scenarios)

About speeds -- even today most keyboards are USB 1.1 low-speed (1.5Mb/s), only a few made the transition to USB 1.1/2.0 full-speed (12Mb/s) so far. I'm not aware of any board that implements USB 2.0 hi-speed (480Mb/s, a bit overkill for a keyboard anyways ) While it is true that the data payload sizes for a single transfer are 8, 64, and 1024 bytes (low-, full-, and hi-speed) you still can send larger reports via multiple transfers.

Are you sure that full-speed supports only 64 bytes for playload? I read this source which said, that the payload size is 1023 bytes and with high speed 1024 bytes.

[Grendel]

What makes NKRO over USB annoying is that a keyboard report has to be able to carry the state of the whole keyboard. PS/2 only transfers key up/down events and pushes remembering the state to the computer. A full blown USB host stack is fairly complicated to implement, esp. if you try to squeeze it into a BIOS. To mitigate this the USB-IF specified the "boot protocol" for keyboards and mice, allowing BIOS's to read these devices w/ minimal programming. The boot-protocol report of a keyboard has a pre-defined layout, one byte that carries the modifiers as a bitmap, one reserved byte, and six bytes that can carry a key code each, hence 6KRO (+ eight mods.) Unfortunately most keyboard manufacturers kept this format for the regular mode in order to keep their firmware/hardware as simple as possible.

The same thoughts as above. 1 bit for each key but with low speed you "need" one byte for a key (=6 Keys). Thats a part I dont understand atm.
Can you tell me what problems in the BIOS can occur when you use a USB full NKRO has a crappy firmware and you use e.g. more then six keys at one time (or other scenarios)

The 1 bit-per-key and 1 byte-per-key has nothing to do with the speed. In a nutshell, a key can either be encoded as bit in a bitfield (the host has to parse the report descriptor to know what each bit in the field stands for) or it's 8-bit code (aka "usage") can be send as a 8-bit number in an array of numbers. The bits have fixed positions, the numbers don't. It's way easier to just grab a number than to analyse each bit in a field to figure out what the numbers are, hence the simplistic 8-byte boot protocol definition so BIOS's need minimal code to deal w/ USB boards and mice. Again, keyboards not implementing NKRO is caused by keeping it as cheap as possible (not changing protocols around saves a lot of firmware work.)

About speeds -- even today most keyboards are USB 1.1 low-speed (1.5Mb/s), only a few made the transition to USB 1.1/2.0 full-speed (12Mb/s) so far. I'm not aware of any board that implements USB 2.0 hi-speed (480Mb/s, a bit overkill for a keyboard anyways ) While it is true that the data payload sizes for a single transfer are 8, 64, and 1024 bytes (low-, full-, and hi-speed) you still can send larger reports via multiple transfers.

Are you sure that full-speed supports only 64 bytes for playload? I read this source which said, that the payload size is 1023 bytes and with high speed 1024 bytes.

For interrupt endpoints, yes (see also the USB 2.0 Spec, chapter 5.7.3.) HID class devices use interrupt endpoints.

[Panp858]

Thank you for your help Grendel. This clears out a lot.