83

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!

Improve this question
13
  • 40
    e.g. it may receive status of lock keys. Many keyboards has leds indicating status of lock keys. Try to switch on caps lock, then replace your keyboard, likely the state will still be locked, this information need to come from the pc.
    – Máté Juhász
    Commented Mar 6, 2017 at 15:34
  • 8
    even PS/2 keyboards receive signals from the PC, otherwise how can it turn on/off the LEDs?
    – phuclv
    Commented Mar 6, 2017 at 16:30
  • 9
    @Devsman you can't do that, otherwise the lock state will be out of sync because it can be changed by software. For example if you plug 2 keyboards and press numlock on this, the LED on the other would toggle. The same can be achieved with on screen keyboard
    – phuclv
    Commented Mar 7, 2017 at 1:03
  • 3
    Toggling the LEDs codegolf.stackexchange.com/questions/110974/blink-the-caps-lock
    – Dohn Joe
    Commented Mar 7, 2017 at 13:38
  • 7
    A USB device must have bi-directional data, simply due to the requirements of the initial handshaking to enable the particular device class.
    – Steve
    Commented Mar 7, 2017 at 20:01

5 Answers 5

Reset to default
101
+50

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.

Improve this answer
9
  • 17
    If we're talking about stuff on a "signals" level, even if we forget enumeration and LEDs, USB input is based on polling. A device can't proactively send data to the host unless the host asks for it. An input device is just polled very frequently to ask if it has anything new to report.
    – Matti Virkkunen
    Commented Mar 6, 2017 at 18:19
  • You mean "output-only" right?
    – Daniel
    Commented Mar 6, 2017 at 18:41
  • Not sure how to word that tbh, a keyboard is an "input" device, and "input-only" would mean it only sends data to the host, but never receives. Depends on if point of view is keyboard or host.
    – LawrenceC
    Commented Mar 6, 2017 at 18:44
  • 1
    @Daniel most people won't call keyboard an "output" device. Peripherals are externally attached so we stand from the PC's perspective to call them input or output. It's the PC we want to use, not keyboard, mouse or other peripherals
    – phuclv
    Commented Mar 7, 2017 at 2:30
  • @LưuVĩnhPhúc I know, but he writes So it is not an "input-only" device (meaning it only outputs data to the host) which confuses me
    – Daniel
    Commented Mar 7, 2017 at 7:51
56

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: enter image description here

(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.

Improve this answer
19

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.

Improve this answer
3
  • If keyboard has any key pressed/depressed, the keyboard will return this information - how would ghost keys occur then? I was under the impression that keyboards must send key-up and key-down events, which would explain why if a key-up event got missed you would have ghost keys...
    – Shadow
    Commented Mar 8, 2017 at 5:47
  • 3
    @shadow , not sure what do you asking about. Polling rate for keyboard, if I recall, is 8 ms. You are pressing keys asynchronously, so some events (make or break) can go into different polling frames, some event will occurs exactly when the IN request is in progress. A good keyboard controller should properly handle all event crossings, and should not have missing events. I have no idea why keyboards generate "ghost keys", but it has nothing to do with USB protocol.
    – Ale..chenski
    Commented Mar 8, 2017 at 6:21
  • 5
    Ghost keys are related to the way the physical keys are wired. Cheaper keyboard controllers do not have a single pin for each key, rather they have a grid system of addressing with e.g. rows and columns where the controller asserts the column wire, and looks for the signal on the row wire. In this scenario pressing two keys e.g. E and S simultaneously may be indistinguishable from pressing W and D, except by timing.
    – Ben
    Commented Mar 8, 2017 at 12:19
3

As other answers have explained, USB requires bi-directional communication as part of the way that it works. PS/2, while allowing bi-directional communication, doesn't require it in order to send keys to the computer, but does require it to set the keyboard LEDs.

Theoretically, you could build a device to duplicate the PS/2 signal and send it to a second computer, and discard any commands from the computers, so you'd be able to send your keypresses to multiple computers but the keyboard LEDs wouldn't respond to the num lock, caps lock, and scroll lock states (or any other change of LED state, for example in Linux the keyboard LEDs are sometimes used for alternative purposes).

I'm not sure how complex such a project would be. It's been a while since I worked with PS/2, so I don't know if you could simply bridge a couple of wires/connectors or if you would need an active device (e.g. microcontroller) to pass commands in one direction but discard them in the other. If you did have a microcontroller, you could even make the device such that it can interpret the keyboard LED commands and "combine" them for display (e.g. long flash the LED if it is on on computer one but off on computer two, short flash the LED if it is on on computer two but off on computer one, LED steady on if it is on on both computers, and LED off if it is off on both computers). That would be more advanced though.

Also, if your goal is to be able to control one computer from another computer, or two computers from the same desk, or whatever, you might want to look into:

  • VNC (allows controlling one computer from another over a network)
  • RDP (also allows controlling one computer from another over a network, built into Microsoft Windows but requires the Professional version)
  • KVM (a piece of hardware that lets you switch one set of peripherals between two computers)
Improve this answer
1

Prior to USB keyboards, the PS/2 keyboards used a much simpler protocol where it is possible to have one keyboard connected to 2 devices and have it work. A simple Y connection is all that is required.

Older USB keyboards still have PS/2 emulation mode built in; using one of those purple connector adapters lets you plug it into a PS/2 port on the back of a computer. So, using a USB to PS/2 breakout cable on 2 computers, then a purple adapter back to your USB keyboard may well work.

Newer USB keyboards dropped the legacy PS/2 mode, so won't work for this case.

Improve this answer
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .