3 ms·

Not true. A USB keyboard must declare the number of simultaneously pressed keys it is able to report. It just happens that the example descriptor included in th

by Zr40 13y ago

Not true. A USB keyboard must declare the number of simultaneously pressed keys it is able to report. It just happens that the example descriptor included in the USB spec has this value set to 6.

qnaal 13y ago
'USB spec'- so it's up to the keyboard driver your operating system provides to actually set the limit? And other than that, there's no artifact of the protocol that would hinder the development of such support?
- kevingadd 13y ago
  Descriptors are provided by devices, not drivers.
  - qnaal 13y ago
    Sorry, I'm not very familiar with how the usb protocol works- but I meant, that not all OS-provided keyboard drivers support devices with up to 100-whatever simultaneous keypresses, right? I've seen keyboards with what looked like hardware 'nkro' toggles, and overheard discussions to the effect that many implementations of nkro over usb are sometimes 'unreliable', which sounds like inexcusable behavior on either part of the keyboard's controller, the software driver, or the protocol itself.
dfox 13y ago
Resulting HID report has to fit into 8 byte payload of low speed interrupt frame, which works out as 6 bytes for keys, 1 byte for LED states (which is arguably redundant) and one byte for modifier keys. On the other hand I can't understand why they had designed HID in this way, when essentially all previous PC keyboard interfaces worked by sending state changes (key down/key up) and not full state. It's not like that generating down/up events would add significant complexity to keyboard, there has to be whole lot of stuff for the USB itself and also it's already there for PS/2.
phaker 13y ago
It's not just that. USB nkro keyboards can fail in several interesting ways, so they earned a bad reputation. Paradoxically the hacks that work around the standard (e.g. a keyboard reports as several devices behind a usb hub) are more reliable, so many keyboards use that instead. There are several cases of driver bugs you have to work around and ignoring driver bugs, it's just generally much harder than it should be (which means more device bugs): * USB HID specifies two interfaces: the full report interface and a simplified "boot interface" that lets you avoid parsing interface descriptors. The boot interface supports only 6 keys, low speed and it's supposed to be used by bioses etc. Some host devices (like TVs) use the boot interface, those can't support more than 6kro. * A USB device can specify several interfaces, the host selects which one it'll use to talk to it. For HID devices the boot interface (if supported) has to come first. The problem is that sometimes the first one is selected as it's the "default" one. It's not really supposed to happen but when it does, you can't have more than 6kro. * The number of simultaneous keys a keyboard (one of its interfaces) can report is specified in its interface descriptor. The USB HID spec contains few sentences that can be easily misunderstood to mean that if a keyboard can report more than simultaneous 6 keys, it doesn't support the boot interface. Some bios writers read it that way, so if you have a fully compliant keyboard with nkro, it will fail on some (buggy) bioses. * USB specifies low-speed (1.5Mbit/s) and full-speed (12Mbit/s) operation (2.0 adds high speed and 3.0 adds super speed). At low speed the payload length of the interrupt frames the HID devices use are limited to 8 bytes, which limits them to 6 keys (one byte is used for modifiers, one is reserved) for one frame messages. It's possible to chain multiple frames per message, but some OSes don't support that. This means that a nkro low-speed keyboard will (on buggy oses) have only 6kro. * A way to work around the last problem is to make a keyboard that uses the full-speed interface. The problem is that one some systems this fails hard (the keyboard doesn't work at all). (source: I wanted to make my own dream keyboard. The existing USB HID device implementations i could find had various limitations so I decided that i'd make my own one. I mean, hey, how hard could it be?)

by Zr40 13y ago

Not true. A USB keyboard must declare the number of simultaneously pressed keys it is able to report. It just happens that the example descriptor included in the USB spec has this value set to 6.

qnaal 13y ago

'USB spec'- so it's up to the keyboard driver your operating system provides to actually set the limit? And other than that, there's no artifact of the protocol that would hinder the development of such support?

kevingadd 13y ago
Descriptors are provided by devices, not drivers.
- qnaal 13y ago
  Sorry, I'm not very familiar with how the usb protocol works- but I meant, that not all OS-provided keyboard drivers support devices with up to 100-whatever simultaneous keypresses, right? I've seen keyboards with what looked like hardware 'nkro' toggles, and overheard discussions to the effect that many implementations of nkro over usb are sometimes 'unreliable', which sounds like inexcusable behavior on either part of the keyboard's controller, the software driver, or the protocol itself.

dfox 13y ago

Resulting HID report has to fit into 8 byte payload of low speed interrupt frame, which works out as 6 bytes for keys, 1 byte for LED states (which is arguably redundant) and one byte for modifier keys. On the other hand I can't understand why they had designed HID in this way, when essentially all previous PC keyboard interfaces worked by sending state changes (key down/key up) and not full state. It's not like that generating down/up events would add significant complexity to keyboard, there has to be whole lot of stuff for the USB itself and also it's already there for PS/2.

phaker 13y ago

It's not just that. USB nkro keyboards can fail in several interesting ways, so they earned a bad reputation. Paradoxically the hacks that work around the standard (e.g. a keyboard reports as several devices behind a usb hub) are more reliable, so many keyboards use that instead. There are several cases of driver bugs you have to work around and ignoring driver bugs, it's just generally much harder than it should be (which means more device bugs): * USB HID specifies two interfaces: the full report interface and a simplified "boot interface" that lets you avoid parsing interface descriptors. The boot interface supports only 6 keys, low speed and it's supposed to be used by bioses etc. Some host devices (like TVs) use the boot interface, those can't support more than 6kro. * A USB device can specify several interfaces, the host selects which one it'll use to talk to it. For HID devices the boot interface (if supported) has to come first. The problem is that sometimes the first one is selected as it's the "default" one. It's not really supposed to happen but when it does, you can't have more than 6kro. * The number of simultaneous keys a keyboard (one of its interfaces) can report is specified in its interface descriptor. The USB HID spec contains few sentences that can be easily misunderstood to mean that if a keyboard can report more than simultaneous 6 keys, it doesn't support the boot interface. Some bios writers read it that way, so if you have a fully compliant keyboard with nkro, it will fail on some (buggy) bioses. * USB specifies low-speed (1.5Mbit/s) and full-speed (12Mbit/s) operation (2.0 adds high speed and 3.0 adds super speed). At low speed the payload length of the interrupt frames the HID devices use are limited to 8 bytes, which limits them to 6 keys (one byte is used for modifiers, one is reserved) for one frame messages. It's possible to chain multiple frames per message, but some OSes don't support that. This means that a nkro low-speed keyboard will (on buggy oses) have only 6kro. * A way to work around the last problem is to make a keyboard that uses the full-speed interface. The problem is that one some systems this fails hard (the keyboard doesn't work at all). (source: I wanted to make my own dream keyboard. The existing USB HID device implementations i could find had various limitations so I decided that i'd make my own one. I mean, hey, how hard could it be?)