Editing USB

'''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.<ref group="footnote">"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>
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 [[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===
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="footnote">Some keyboards carry passthrough not only for a second USB bus but also for analogue headphone and microphone jacks.</ref>
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===
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.<ref group="footnote">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</ref>

==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 [[Rollover, blocking and ghosting|''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.<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===
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.

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.<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" 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.<ref name="intelrf">Intel—[https://www.intel.com/content/www/us/en/products/docs/io/universal-serial-bus/usb3-frequency-interference-paper.html USB 3.0* Radio Frequency Interference on 2.4 GHz Devices]. Dated April 2012. Retrieved 2019-09-05</ref>

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==
<references group="footnote"/>

==External links==
* Beyond Logic—[https://www.beyondlogic.org/usbnutshell/usb1.shtml USB in a NutShell]. An introduction to USB programming.

==See also==
* [[NKRO-over-USB issues]]
* [[Rollover, blocking and ghosting]]

==References==
<references/>

[[Category:Keyboard protocols and interfaces]]
[[Category:Pointing device protocols and interfaces]]
[[Category:Game controller protocols and interfaces]]