Difference between revisions of "USB"
(Removed stub template.) |
m (Normalized references and external link, modified some wording.) |
||
| Line 1: | Line 1: | ||
| − | '''Universal Serial Bus''', commonly referred to as '''USB''', is a modern peripheral interface that is the currently predominant method for connecting keyboards and mice. | + | '''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. |
| − | 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. | + | 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. |
| − | USB HID devices typically use USB 2.0, even over newer connectors. | ||
==Topology== | ==Topology== | ||
| − | Each USB bus is controlled by its host. | + | 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". |
| − | Unlike e.g. PS/2 where a device sends bytes whenever it has input, a USB device talks only when asked by the host | ||
| − | 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 | + | 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 at. The host then decides how to configure the device — or to ''not'' configure it. |
===Power management=== | ===Power management=== | ||
| − | A device has to request for the amount of power to use when it has been configured. | + | A device has to request for the amount of power to use when it has been configured. The limit is 500 mA.<ref group="Note" name="default-power" /> An unconfigured device is not allowed to draw more than 100 mA. |
| − | The limit is 500 mA.<ref group=" | ||
| − | A | + | 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 [[Keyboard controller|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. | |
| − | |||
| − | |||
| − | Many devices break these rules however, especially firmware for DIY keyboards. | ||
| − | For instance PJRC's USB code for AVR [[Keyboard controller|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=== | ===Hubs=== | ||
USB does not have daisy-chaining (like [[ADB]]) but allows tree-shaped networks with a "hub" in each node. | 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.<ref group=" | + | When a device has one or more external ports, then 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.<ref group="Note" name="passthrough" /> 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 keyboard]]s that request all the power. |
| − | 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 keyboard]]s that request all the power. | ||
===Logical interfaces=== | ===Logical interfaces=== | ||
USB allows a peripheral device to expose multiple logical ''interfaces'', to perform multiple roles. | 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. | + | 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. 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. |
==Human Interface Device== | ==Human Interface Device== | ||
| − | The '''Human Interface Device''' (HID) subprotocol is used for USB input devices including keyboards, pointing devices and game controllers. | + | 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 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. | + | 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]]. |
| − | A computer with an integrated input device or proprietary keyboard connector could even use HID over [[I²C]]. | ||
===Report Descriptor=== | ===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. | + | 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 [[Rollover, blocking and ghosting|''n''-key rollover]] over full-speed (or greater) USB. |
| − | This complex report descriptor language should | ||
| − | Unfortunately, because of its complexity, the standard has not been interpreted the same everywhere and there have been (or are) | + | Unfortunately, because of its complexity, the standard has not been interpreted the same everywhere and there have been (or still are) slight differences in how host implementations work. For instance, MacOS X does not permit the same key to be reported twice.<ref name="ghthefloweringash" /> |
| − | For instance, MacOS X does not permit the same key to be reported twice.<ref name="ghthefloweringash" | ||
===Keyboard Boot Protocol=== | ===Keyboard Boot Protocol=== | ||
| − | To avoid complexity in simpler USB stacks, such as those used in PC BIOS | + | 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". 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. |
| − | 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. | + | 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==== | ====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. | 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: | + | 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. | * 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. | ||
| Line 69: | Line 54: | ||
====Workaround==== | ====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 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. |
| − | The change-overs happen when the boot keyboard receives "Set Protocol" requests, which (standards-compliant) BIOS | ||
| − | [[Soarer's | + | [[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" /> |
| − | 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" | ||
==Super-speed USB interference on wireless devices== | ==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]]. | + | "Super-speed" data-transfers over USB 3.0 (and later) could cause interference on wireless protocols operating in the 2.4GHz band, such as [[Bluetooth]] and [[Logitech Unifying]]. |
| − | + | A USB 3 port, cable or USB 3 device (such as a flash drive) may emit signals that translate to noise for the wireless protocol. This can result in input lag, or even make a mouse unresponsive.<ref name="intelrf" /> | |
Ways to minimise interference: | Ways to minimise interference: | ||
* Connect wireless receivers and drives on ports far from each other (such as on different sides of a laptop) | * 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 | * Put the receiver closer to the input device, using an USB extension cord | ||
| − | * Use external | + | * Use external hard drives contained in drive enclosures made of metal |
* Use shielded USB 3.0 cables | * Use shielded USB 3.0 cables | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==See also== | ==See also== | ||
* [[NKRO-over-USB issues]] | * [[NKRO-over-USB issues]] | ||
* [[Rollover, blocking and ghosting]] | * [[Rollover, blocking and ghosting]] | ||
| + | |||
| + | ==Footnotes== | ||
| + | <references group="Note"> | ||
| + | <ref group="Note" name="default-power">"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.</ref> | ||
| + | <ref group="Note" name="passthrough">Some keyboards carry passthrough not only for a second USB bus but also for analogue headphone and microphone jacks.</ref> | ||
| + | </references> | ||
==References== | ==References== | ||
| − | <references/> | + | <references> |
| + | <ref name="ghthefloweringash">Geekhack — [https://geekhack.org/index.php?topic=24672.msg465054#msg465054 Noppoo Choc Mini on MacOS] by thefloweringash. Posted 2011-12-06. Retrieved 2024-05-18.</ref> | ||
| + | <ref name="ghsoarer">Geekhack — [https://geekhack.org/index.php?topic=38786.msg1064755#msg1064755 Re: Are there any USB NKRO keyboards on the market yet?] by Soarer. Posted 2013-10-04. Retrieved 2024-05-18.</ref> | ||
| + | <ref name="intelrf">Intel — [https://www.usb.org/sites/default/files/327216.pdf Document 327216-001: USB 3.0* Radio Frequency Interference Impact on 2.4 GHz Wireless Devices] (direct download) (USB Implementers Forum) Dated April 2012. Retrieved 2024-05-18.</ref> | ||
| + | </references> | ||
| + | |||
| + | ==External links== | ||
| + | * Beyond Logic — [https://www.beyondlogic.org/usbnutshell/usb1.shtml USB in a NutShell: Making sense of the USB standard] Retrieved 2024-05-18. | ||
[[Category:Keyboard protocols and interfaces]] | [[Category:Keyboard protocols and interfaces]] | ||
[[Category:Pointing device protocols and interfaces]] | [[Category:Pointing device protocols and interfaces]] | ||
[[Category:Game controller protocols and interfaces]] | [[Category:Game controller protocols and interfaces]] | ||
Latest revision as of 01:03, 18 May 2024
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.
Contents
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 at. 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.[Note 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, then 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.[Note 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. 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.
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 still are) 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 operating in the 2.4GHz band, such as Bluetooth and Logitech Unifying.
A USB 3 port, cable or USB 3 device (such as a flash drive) may emit signals that translate to noise for the wireless protocol. This can result in 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 hard drives contained in drive enclosures made of metal
- Use shielded USB 3.0 cables
See also
Footnotes
- ↑ "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.
- ↑ Some keyboards carry passthrough not only for a second USB bus but also for analogue headphone and microphone jacks.
References
- ↑ Geekhack — Noppoo Choc Mini on MacOS by thefloweringash. Posted 2011-12-06. Retrieved 2024-05-18.
- ↑ Geekhack — Re: Are there any USB NKRO keyboards on the market yet? by Soarer. Posted 2013-10-04. Retrieved 2024-05-18.
- ↑ Intel — Document 327216-001: USB 3.0* Radio Frequency Interference Impact on 2.4 GHz Wireless Devices (direct download) (USB Implementers Forum) Dated April 2012. Retrieved 2024-05-18.
External links
- Beyond Logic — USB in a NutShell: Making sense of the USB standard Retrieved 2024-05-18.
