Difference between revisions of "USB"

From Deskthority wiki
Jump to navigation Jump to search
(Mentioned Bluetooth and I²C.)
(Keyboard Boot Protocol and NKRO)
Line 51: Line 51:
 
For instance, MacOS X does not permit the same key to be reported twice.<ref name="ghthefloweringash">Post by '''thefloweringash''' on Geekhack—[https://geekhack.org/index.php?topic=24672.0 Noppoo Choc Mini on MacOS]. Dated 2011-12-06</ref>
 
For instance, MacOS X does not permit the same key to be reported twice.<ref name="ghthefloweringash">Post by '''thefloweringash''' on Geekhack—[https://geekhack.org/index.php?topic=24672.0 Noppoo Choc Mini on MacOS]. Dated 2011-12-06</ref>
  
===Keyboard Boot Protocol and NKRO===
+
===Keyboard Boot Protocol===
To avoid complexity in boot code, such as PC BIOS:es and bootloaders, the USB HID specification says that a keyboard or mouse interface that is "boot-capable" should use special hard-coded protocols when talking to BIOS:es, and to be able to switch back and forth between this and their regular protocol on ("Set Protocol") requests from the host.
+
To avoid complexity in simpler USB stacks, such as those used in PC BIOS:es and bootloaders and [[KVM switch]]es, the USB HID standard specifies that keyboards (and mice) could also declare themselves to be "boot-capable".
It also requires that each regular (non-boot) protocol be a superset of the corresponding boot protocol and that a report not be larger than eight bytes.
+
Being "boot-capable" means that the keyboard (or mouse) would be able to switch to/from its regular fully-featured protocol to a special simpler hard-coded "Boot Protocol" that the simpler USB stack would understand. The switch would be done on special "Set Protocol" requests that only boot-capable devices would understand.
<!-- I read somewhere that someone tested sending "boot keyboard" reports larger than 8 bytes to some BIOS:es which caused them to crash... However, I have lost the reference. /Findecanor
 
-->
 
  
The ''keyboard boot protocol'' is however eight bytes long already, which means that
+
The boot protocol for keyboards imposes a limitation of six concurrent keys plus modifiers to be pressed at one time. This behaviour is referred to as 6-key rollover, or 6KRO.
boot-capable keyboards must in practice speak the boot protocol always.
 
<ref group="footnote">The "boot mouse" protocol however is only 3 bytes, which means that a boot-capable mouse interface's reports could have up to five additional bytes that a BIOS would just ignore.</ref>.
 
This protocol imposes a limit of six arbitrary keys plus modifiers to be pressed at one time.
 
This limit is referred to as [[Rollover, blocking and ghosting|6-key rollover]], or 6KRO.
 
  
If a keyboard interface is ''not'' a "boot keyboard" however, then its report format is not restricted and could be capable of N-key rollover
+
====Protocol problem====
 +
The USB HID specification is unfortunately vague about one detail of the boot protocols: the specification ''could'' be interpreted as requiring that a mouse or keyboard's regular (non-boot) protocol be a superset of the corresponding boot protocol, and to be limited to eight bytes in size. The ''keyboard boot protocol'' is however eight bytes long already, which means that boot-capable keyboards would in practice need to speak the boot protocol always.
  
Some keyboards work around this problem by allowing the user to select between 6-key and NKRO with a DIP switch or special key combination.
+
Different engineers of either BIOS'es and keyboards have interpreted the specification differently on this point ... or engineered to be compatible with both interpretations:
  
The trick to supporting both boot and NKRO is for the keyboard to expose two interfaces — one boot interface and one NKRO interface — but to not send (valid) reports on both at the same time.
+
* Some BIOS'es are overly simplified in that they would not send the required "Set Protocol" request to a Boot-capable keyboard. Such a BIOS could work incorrectly together with a keyboard designed according to the opposing interpretation of the standard.
The change-overs happen when the boot keyboard receives "Set Protocol" requests, which (some) BIOS:es and all fully-fledged operating systems send.
 
  
[[Soarer's Converter]] and firmware employ a variation of this trick, known to work with both Windows, MacOS and Linux. The 6KRO "boot" protocol is sent always but the report descriptor for that interface describes it as containing no keys. Therefore, only a BIOS (which does not read report descriptors) would read from that interface but ignore the non-boot interface, and vice versa.<ref name="ghsoarer">Post by '''Soarer''' on Geekhack—[https://geekhack.org/index.php?topic=38786.msg1064755#msg1064755 Re:Are there any USB NKRO keyboards on the market yet?]. Posted 2013-10-04. Retrieved 2016-03-06.</ref>
+
* Many keyboards use only the simple 6KRO boot-protocol, as being able to enter BIOS is considered a vital feature and/or because supporting only one protocol is simpler and "good enough".
 +
 
 +
* Some keyboards that ''do'' support N-key rollover are not boot-capable, and do nothing in BIOS.
 +
 
 +
Other keyboards with NKRO work around this problem by allowing the user to select between 6KRO boot-protocol and NKRO with a DIP switch or special key combination.
 +
 
 +
====Workaround====
 +
The trick for supporting both Boot Keyboard and NKRO is for the keyboard to expose ''two interfaces'' — as if it was two keyboards. One is a boot-capable keyboard interface and the other is a keyboard interface with N-key rollover, but with only one being active at the same time.
 +
The change-overs happen when the boot keyboard receives "Set Protocol" requests, which (standards-compliant) BIOS:es and all fully-fledged operating systems send.
 +
 
 +
[[Soarer's Converter]] and firmware employ a variation of this trick, known to work with both Windows, MacOS and Linux and also with the non-compliant BIOS'es mentioned above.
 +
The 6KRO "boot" protocol is sent always but the report descriptor for that interface describes it as containing no keys. Therefore, only a BIOS (which does not read report descriptors) would read from that interface but ignore the non-boot interface, and vice versa.<ref name="ghsoarer">Post by '''Soarer''' on Geekhack—[https://geekhack.org/index.php?topic=38786.msg1064755#msg1064755 Re:Are there any USB NKRO keyboards on the market yet?]. Posted 2013-10-04. Retrieved 2016-03-06.</ref>
  
 
==Super-speed USB interference on wireless devices==
 
==Super-speed USB interference on wireless devices==

Revision as of 23:13, 11 May 2020

This article is a stub. You can help Deskthority by expanding it.

Universal Serial Bus, commonly referred to as USB, is a modern peripheral interface that is the currently predominant method for connecting keyboards and mice. USB allows for the connection of a vast range of peripherals to computers, including printers, network adaptors, microphones, displays and hard drives.

Input devices such as keyboards, mice and game controllers use the Human Interface Device (HID) subprotocol. USB HID devices typically use USB 2.0, even over newer connectors.

Topology

Each USB bus is controlled by its host. Unlike e.g. PS/2 where a device sends bytes whenever it has input, a USB device talks only when asked by the host: this is often referred to as "polling".

When a device is connected, the device responds with its requirements: its power requirements, what kinds of interface it has, and what speeds those want to run on. The host then decides how to configure the device — or to not configure it.

Power management

A device has to request for the amount of power to use when it has been configured. The limit is 500 mA.[footnote 1] An unconfigured device is not allowed to draw more than 100 mA.

A host could also put a USB bus into "suspend" mode, at which time all devices on the bus (configured or not) are required to go into suspend mode themselves. A suspended device is not allowed to draw more than 2.5 mA.

Many devices break these rules however, especially firmware for DIY keyboards. For instance PJRC's USB code for AVR microcontrollers (Teensy 2.0) did not originally support suspend mode, and many keyboards with backlighting and/or underglow are lit before they have been configured.

Hubs

USB does not have daisy-chaining (like ADB) but allows tree-shaped networks with a "hub" in each node.

When a device has one or more external ports, either the device itself and its ports are all under the hub or the port is a pass-through through the device cable to a separate plug on the host side.[footnote 2] A hub can be powered or not powered. On a non-powered hub over USB 2.0 devices must share 500 mA power from the host between them (and the hub itself). This can cause problems with some backlit keyboards that request all the power.

Logical interfaces

USB allows a peripheral device to expose multiple logical interfaces, to perform multiple roles.

For instance, a peripheral could be both a keyboard and a mouse, or a keyboard and a storage device, each on a separate logic interface.[footnote 3]

Human Interface Device

The Human Interface Device (HID) subprotocol is used for USB input devices including keyboards, pointing devices and game controllers. HID over USB does not need fast data transfers, so HID devices should work with USB 2.0 ports, or even earlier versions.

HID is also used by Bluetooth peripherals. A computer with an integrated input device or proprietary keyboard connector could even use HID over I²C.

Report Descriptor

The USB-HID requires that every peripheral declares its report format in a "Report Descriptor", defined in a binary language that needs to be parsed on the host side. This complex report descriptor language should —in theory— allow for a very large number of different report formats, including keyboards for n-key rollover over full-speed (or greater) USB.

Unfortunately, because of its complexity, the standard has not been interpreted the same everywhere and there have been (or are) still slight differences in how host implementations work. For instance, MacOS X does not permit the same key to be reported twice.[1]

Keyboard Boot Protocol

To avoid complexity in simpler USB stacks, such as those used in PC BIOS:es and bootloaders and KVM switches, the USB HID standard specifies that keyboards (and mice) could also declare themselves to be "boot-capable". Being "boot-capable" means that the keyboard (or mouse) would be able to switch to/from its regular fully-featured protocol to a special simpler hard-coded "Boot Protocol" that the simpler USB stack would understand. The switch would be done on special "Set Protocol" requests that only boot-capable devices would understand.

The boot protocol for keyboards imposes a limitation of six concurrent keys plus modifiers to be pressed at one time. This behaviour is referred to as 6-key rollover, or 6KRO.

Protocol problem

The USB HID specification is unfortunately vague about one detail of the boot protocols: the specification could be interpreted as requiring that a mouse or keyboard's regular (non-boot) protocol be a superset of the corresponding boot protocol, and to be limited to eight bytes in size. The keyboard boot protocol is however eight bytes long already, which means that boot-capable keyboards would in practice need to speak the boot protocol always.

Different engineers of either BIOS'es and keyboards have interpreted the specification differently on this point ... or engineered to be compatible with both interpretations:

  • Some BIOS'es are overly simplified in that they would not send the required "Set Protocol" request to a Boot-capable keyboard. Such a BIOS could work incorrectly together with a keyboard designed according to the opposing interpretation of the standard.
  • Many keyboards use only the simple 6KRO boot-protocol, as being able to enter BIOS is considered a vital feature and/or because supporting only one protocol is simpler and "good enough".
  • Some keyboards that do support N-key rollover are not boot-capable, and do nothing in BIOS.

Other keyboards with NKRO work around this problem by allowing the user to select between 6KRO boot-protocol and NKRO with a DIP switch or special key combination.

Workaround

The trick for supporting both Boot Keyboard and NKRO is for the keyboard to expose two interfaces — as if it was two keyboards. One is a boot-capable keyboard interface and the other is a keyboard interface with N-key rollover, but with only one being active at the same time. The change-overs happen when the boot keyboard receives "Set Protocol" requests, which (standards-compliant) BIOS:es and all fully-fledged operating systems send.

Soarer's Converter and firmware employ a variation of this trick, known to work with both Windows, MacOS and Linux and also with the non-compliant BIOS'es mentioned above. The 6KRO "boot" protocol is sent always but the report descriptor for that interface describes it as containing no keys. Therefore, only a BIOS (which does not read report descriptors) would read from that interface but ignore the non-boot interface, and vice versa.[2]

Super-speed USB interference on wireless devices

"Super-speed" data-transfers over USB 3.0 (and later) could cause interference on wireless protocols in the 2.4GHz band, such as Bluetooth and Logitech Unifying.

Both a USB 3 port, cable or USB 3 device (such as a flash drive) could radiate signals that occur as noise on the wireless protocol. This can cause input lag, or even make a mouse unresponsive.[3]

Ways to minimise interference:

  • Connect wireless receivers and drives on ports far from each other (such as on different sides of a laptop)
  • Put the receiver closer to the input device, using an USB extension cord
  • Use external harddrives only in external drive enclosures made of metal
  • Use shielded USB 3.0 cables

Footnotes

  1. "Default power" of 500 mA is for USB 2.0 devices. USB 3.0 devices and later could draw up to 900 mA but HID devices that declare themselves as being more than USB 2.0 are very rare. A power source could provide more power, but more than default is not guaranteed, even over USB Type C.
  2. Some keyboards carry passthrough not only for a second USB bus but also for analogue headphone and microphone jacks.
  3. One device known to actually be both a keyboard and a storage device is the Kinesis Advantage 2, where the storage device is used for changing the keyboard's firmware and settings

External links

See also

References

  1. Post by thefloweringash on Geekhack—Noppoo Choc Mini on MacOS. Dated 2011-12-06
  2. Post by Soarer on Geekhack—Re:Are there any USB NKRO keyboards on the market yet?. Posted 2013-10-04. Retrieved 2016-03-06.
  3. Intel—USB 3.0* Radio Frequency Interference on 2.4 GHz Devices. Dated April 2012. Retrieved 2019-09-05