Difference between revisions of "Background: How keyboards work"

From Linuxintro
imported>ThorstenStaerk
(damned xml dump)
imported>ThorstenStaerk
Line 1: Line 1:
Keyboards typically are connected to the computer via a [[USB]] or a [http://en.wikipedia.org/wiki/PS/2_connector PS/2] cable. They send signals when they transfer data, when they acknowledge and when their buffer is full or empty. The kernel receives these signals and, depending on the loaded kernel module (provided the kernel does not do the work itself), sends the data to /dev/tty0. The application (typically X or a [[shell]]) gets these signals and puts them into a queue, like [[stdin]]. The value received by X from the kernel will be the key's ''scancode''. Which scancode it is you can find out with the command [[xev]]. To change the mapping of scancode to X events, you can use the [[xmodmap]] command.
+
Keyboards typically are connected to the computer via a [[USB]] or a [http://en.wikipedia.org/wiki/PS/2_connector PS/2] cable. They send signals when they transfer data, when they acknowledge and when their buffer is full or empty. The kernel receives these signals and, depending on the loaded kernel module (provided the kernel does not do the work itself), sends the data to /dev/tty0. The application (typically X or a [[shell]]) gets these signals and puts them into a queue, like [[stdin]]. The value received by X from the kernel will be the key's ''scancode''. Which scancode it is you can find out with the command xev. To change the mapping of scancode to X events, you can use the [[xmodmap]] command.
  
 
= The X layer =  
 
= The X layer =  
  
Use [[xev]] to see which keyboard events X sees.
+
Use the command xev to see which keyboard events X sees.
  
 
= The layer beneath X =
 
= The layer beneath X =

Revision as of 13:10, 28 December 2013

Keyboards typically are connected to the computer via a USB or a PS/2 cable. They send signals when they transfer data, when they acknowledge and when their buffer is full or empty. The kernel receives these signals and, depending on the loaded kernel module (provided the kernel does not do the work itself), sends the data to /dev/tty0. The application (typically X or a shell) gets these signals and puts them into a queue, like stdin. The value received by X from the kernel will be the key's scancode. Which scancode it is you can find out with the command xev. To change the mapping of scancode to X events, you can use the xmodmap command.

The X layer

Use the command xev to see which keyboard events X sees.

The layer beneath X

To find out what signals X receives from the keyboard, open a new graphical console and type

cat /dev/tty0

You will see the messages that the kernel (and his modules) put into the tty0 device, the keyboard. When you are ready, close the console with a mouse click, as because of obvious reasons, you cannot abort with a keypress.

The kernel layer

If you really want to see what data comes over the wire, you have to write a kernel module, because the i386's security concept will not let anything read data but the kernel. So, create /root/keyb.c:

/*  A kernel module.
*/

#include <linux/module.h>
#include <linux/kernel.h>
#include <asm/io.h>

int init_module(void)
{
  printk("This is a kernel module\n");
  int retries = 0x100100;
  int input;
  while (--retries != 0){int oldinput=input; input=inb(0x60); if (oldinput!=input)
  printk("got %i",input);};
}

void cleanup_module(void)
{
  printk(KERN_ALERT "Au revoir\n");
}

and Makefile:

obj-m += keyb.o

and compile this:

$ make -C /lib/modules/$(uname -r)/build M=$(pwd) modules       

Now when you load this module, the kernel will, during the initialization phase (the while loop) listen to port 0x60 and print the data on wire there. So, be prepared

  • the module will take a little time to initialize
  • during the load phase, you can type a bit and you will see it in the system log
  • this is tested for the PS/2 port, but not for USB

Load the module:

insmod keyb.ko

Check the syslog:

dmesg