Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
When I press a key on the keyboard, I am closing a switch, then what? I know that each character is encoded in ASCII as a byte. For example if I press the "a" key, is the byte 01100001 immediately sent to the cpu. Or, is that number stored in some memory location that the kernel reads periodically?
Click here to see the post LQ members have rated as the most helpful post in this thread.
1. No, when you press the "a" key, you do *not* immediately get an "a".
The hardware generates a "keycode", which is the first of several steps before you finally read a letter "a".
2. No, pressing the key generates an interrupt on your motherboard, which is originally handled by the BIOS. It takes awhile before the kernel finally gets it.
3. No, the kernel doesn't poll the BIOS keyboard buffer. It simply fetches data that's already available (courtesy of the BIOS) when requested.
4. Once an application in user space requests a keystroke from the kernel, then the fun REALLY starts happening. Here's more than you probably ever wanted to know about keyboard handling "at the top of the stack":
You press a key, and the keyboard controller sends scancodes to the kernel keyboard driver. Some keyboards can be programmed, but usually the scancodes corresponding to your keys are fixed. The kernel keyboard driver just transmits whatever it receives to the application program when it is in scancode mode, like when X is running. Otherwise, it parses the stream of scancodes into keycodes, corresponding to key press or key release events. (A single key press can generate up to 6 scancodes.) These keycodes are transmitted to the application program when it is in keycode mode (as used, for example, by showkey and some X servers). Otherwise, these keycodes are looked up in the keymap, and the character or string found there is transmitted to the application, or the action described there is performed. (For example, if one presses and releases the a key, then the keyboard produces scancodes 0x1e and 0x9e, this is converted to keycodes 30 and 158, and then transmitted as 0141, the ASCII or latin-1 code for `a'; if one presses and releases Delete, then the keyboard produces scancodes 0xe0 0x53 0xe0 0xd3, these are converted to keycodes 111 and 239, and then transmitted as the 4-symbol sequence ESC [ 3 ~, all assuming a US keyboard and a default keymap. An example of a key combination to which an action is assigned is Ctrl-Alt-Del.)
The translation between unusual scancodes and keycodes can be set using the utility setkeycodes - only few people will need it. The translation between keycodes and characters or strings or actions, that is, the keymap, is set using the utilities loadkeys and setmetamode. For details, see getkeycodes(8), setkeycodes(8), dumpkeys(1), loadkeys(1), setmetamode(1). The format of the files output by dumpkeys and read by loadkeys is described in keymaps(5).
Where it says `transmitted to the application' in the above description, this really means `transmitted to the terminal driver'. That is, further processing is just like that of text that comes in over a serial line. The details of this processing are set by the program stty.
I know that each character is encoded in ASCII as a byte. For example if I press the "a" key, is the byte 01100001 immediately sent to the cpu.
Your keyboard knows nothing about ASCII. Every time a key is pressed, it emits a few bytes. Each key sends a different code when pressed and when released. These codes have nothing to do with ASCII, not even the letter keys. The kernel then gets those codes, and uses a look-up table (when you change the keyboard layout, you are actually changing this look-up table) to see which key/character the code corresponds to.