Does a USB keyboard only send signals, or does it also receive them from the computer?

The keyboard doesn't need any signal from the computer, just power, right? OR does it need to receive signals as well as send them?

Edit: I didn't expect this question to generate this much interest! I asked it because I had an idle dream of building a doohickey which duplicates the signal so the keyboard could send the same letter to two computers at once. Since (from what I can make out in the answers) the computer actively controls the keyboard like any other device, this clearly isn't possible. Not a big deal as practically I didn't have the skills to build it anyway!

Solution 1:

From the "Device Class Definition for Human Interface Devices (HID)" version 11.1" specification:

Synchronization between LED states and CAPS LOCK, NUM LOCK, SCROLL LOCK, COMPOSE, and KANA events is maintained by the host and NOT the keyboard. If using the keyboard descriptor in Appendix B, LED states are set by sending a 5-bit absolute report to the keyboard via a Set_Report(Output) request.

To change the keyboard LEDs, the keyboard accepts a command to do so. So it is not an "input-only" device (meaning it only outputs data to the host).

That being said, there is a negotiation and enumeration process with all USB devices that require a back-and-forth conversation between host and device. You can't have a "read-only" USB device.

Even before USB, the PC keyboard controller would accept commands because it did a few things besides read the keyboard (reference):

If a keyboard is a separate peripheral system unit (such as in most modern desktop computers), the keyboard controller is not directly attached to the keys, but receives scancodes from a microcontroller embedded in the keyboard via some kind of serial interface. In this case, the controller usually also controls the keyboard's LEDs by sending data back to keyboard through the wire.

The IBM PC AT used an Intel 8042 chip to interface to the keyboard. This computer also controlled access to the A20 line in order to implement a workaround for a chip bug in the Intel 80286.1 The keyboard controller was also used to initiate a software CPU reset in order to allow the CPU to transition from protected mode to real mode1 because the 286 did not allow the CPU to go from protected mode to real mode unless the CPU is reset. This was a problem because the BIOS and the operating system services could only be called by programs in real mode.

These behaviors have been used by plenty of software that expects this behavior, and therefore keyboard controllers have continued controlling the A20 line and performing software CPU resets even when the need for a reset via the keyboard controller was obviated by the Intel 80386's ability to switch to real mode from protected mode without a CPU reset.

Solution 2:

Any USB device regardless of its class requires bidirectional communication to function. Every USB device (or function in terms of USB spec) is represented as a set of endpoints which can be thought of as buffers which accept or receive data. However, even endpoints which can only send data wait for a special packet called token before they can reply:

^{(image from here, gray boxes represent USB host, white boxes represent USB function)}

Even so-called interrupt transfers are done in this way, with USB host polling connected devices using token packets. What differs between regular (bulk) transfers and interrupt transfers is that polling time is small and guaranteed in the latter case. Still, all transfers are initiated by the host.

Solution 3:

The question reflects a common misconception that USB devices "send" something to PC on their own when a key is pressed (or mouse moves), that's why so high attention. In fact, USB devices don't send anything until they RECEIVE corresponing request from host. One exception is a wake-up process from a suspended device.

While the USB looks simple on the surface, in fact its functioning is quite complicated. Any new USB device must be "enumerated" first before it starts functioning. The sequence is as follows:

1. After a keyboard is plugged in, the host port receives "connect status" signal (for LS signals, D- is pulled HIGH by keyboard).

2. Then the host sets the port into "port reset" mode, and the USB PHY (physical layer driver) sends "USB_RESET" down the D+/D- lines (both lines are driven LOW for a prescribed amount of time). Some info on "port reset" for FS/HS devices can be found here.

3. Then the host begins to output frame boundary packets on 1ms interval. For Low-speed (LS) devices as ordinary wired keyboard, these are just "keep alive" pulses, while for FS the special SOF - start-of-frame packets are generated. These packets keep the device in active mode and prevent it from doing into low-power SUSPEND.

4. Then the "enumeration" begins. The host sends a request to get device descriptor. The request is sent to "default pipe" with device address "0". [There is only one such device at this time - the keyboard - since all other devices on the bus already should have their individually assigned USB addresses]

5. The keyboard returns requested information, so the host will be able to determine what kind of driver should be loaded.

6. The host sends a transaction requiring the device to change its default address to new assigned address.

7. Then the host starts new round of communication with the device, now at the new assigned address. All other devices ignore this communication because it is not addressed to them.

8. The host might read a lot more information from several other descriptors, and eventually selects "device configuration". This concludes the process of enumeration.

9. Depending on USB device class, the host starts communicating with the device. In keyboard case, the host sends essentially "IN" request periodically, essentially polling the device (even if this periodic pipe is called "interrupt" pipe). If keyboard has any key pressed/depressed, the keyboard will return this information. If not, no data will be returned to the device driver.

It short, every USB device must receive unique address from USB host, and two USB hosts will have a difficulty to communicate with a device - bus collision, address mismatch, random intercept of keypress data, etc. USB protocol makes it impossible to share a device between two USB hosts.