Welcome to the Power Users community on Codidact!
Power Users is a Q&A site for questions about the usage of computer software and hardware. We are still a small site and would like to grow, so please consider joining our community. We are looking forward to your questions and answers; they are the building blocks of a repository of knowledge we are building together.
What's the protocol for keyboards to communicate which keys were pressed?
For context, suppose I ask (on Linux) a process to report to me about the exact bytes I send it - say, with xxd -. I press the right arrow key on my keyboard, then Enter, then Ctrl-D (to signal the end of input, implicitly quitting the program). And I get:
00000000: 1b5b 430a .[C.
As I might expect from an understanding of ANSI escape codes, the right-arrow keypress has resulted in the xxd program receiving the bytes for an ASCII "escape" character, open square bracket and capital C; the enter key has somehow resulted in a line feed; and the Ctrl-D keypress has seemingly been handled by the terminal and not forwarded to xxd (it simply closes the standard input).
However, I also know that the return key would produce a carriage return - line feed sequence on Windows (so two bytes) if I had an equivalent program there; and that the Escape key produces an escape character by itself (so that e.g. TUI programs need a different way to tell whether the 0x1b byte represents the Escape key or the start of something more complex); and that the OS can implement different "keyboard layouts" for the same physical device (useful for typing text in different languages). Finally, it seems that some games can register whether a modifier key (such as the Shift key) is being held down, even if no letter key is pressed.
What does the overall process look like for getting from physical key presses to a program's standard input? Does the keyboard actually send the same bytes as in the ANSI escape sequences; or does it send bytes that encode some kind of "key ID" for each press; or exactly what? Is it possible to intercept the "raw" keyboard data directly? And where in the system, exactly, does it get translated?
1 answer
Keyboards usually natively send "key codes". These have to do with the physical location of the key on the keyboard and how the keys may be multiplexed. These key codes are received by a driver that knows about the specific keyboard. What happens after that is specific to the operating system.
Some operating system define their own key codes for device-independent internal use. The keyboard driver then has to translate the codes from the keyboard to the official internal generic key codes.
Depending on the interface the driver must support on the OS side, the driver or a low level OS layer then creates "events" for any changes of the keyboard state.
What happens after that can vary greatly. The raw generic keyboard events are usually available to the user in some way. Apps can generally capture these events, and can call generic OS routines to map keys to particular functions (like letters, numbers, Enter, modifier keys, etc). There is also usually a more cooked layer where apps can get the interpreted key presses.
When keyboard input is routed to something like a terminal window, the key actions are interpreted into a series of ASCII (or other encodings) bytes and stuffed into the STDIN FIFO, which apps can read the other end of.
How events are processed and made available to apps is also very dependent on the OS. In Windows for example, apps have to provide a special subroutine that gets called from the system on events. Other systems have an event queue. It's a FIFO that the OS writes events to, and the app gets the next event (or indication there is no pending event) when it asks.
Nowadays, most keyboards use the same set of low level key codes. They were originally arbitrary, and each keyboard needed a custom driver. However, very early on new keyboards were made to be compatible with existing popular keyboards or whatever driver was the default or assumed to come with the system. As a result, most keyboards now use the same key codes. Custom drivers to support a particular model keyboard are still possible, but for obvious reasons vendors want to be compatible with the "standard" keyboard driver when possible.
0 comment threads
0 comment threads