Your IP : 216.73.216.170
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.66">
<TITLE>The Linux Console Tools: Understanding and setting up the keyboard driver</TITLE>
<LINK HREF="lct-6.html" REL=next>
<LINK HREF="lct-4.html" REL=previous>
<LINK HREF="lct.html#toc5" REL=contents>
</HEAD>
<BODY>
<A HREF="lct-6.html">Next</A>
<A HREF="lct-4.html">Previous</A>
<A HREF="lct.html#toc5">Contents</A>
<HR>
<H2><A NAME="s5">5.</A> <A HREF="lct.html#toc5">Understanding and setting up the keyboard driver</A></H2>
<H2><A NAME="ss5.1">5.1</A> <A HREF="lct.html#toc5.1">How it works</A>
</H2>
<P>The keyboard driver is made up several levels:</P>
<P>
<UL>
<LI> the keyboard hardware, which turns the user's finger moves into
so-called <EM>scancodes</EM> (Disclaimer: this is not really part of the
software driver itself; no support is provided for bugs in this domain
;-). An event (key pressed or released) generates from 1 to 6
<EM>scancodes</EM>.
</LI>
<LI> a mechanism turning <EM>scancodes</EM> into <EM>keycodes</EM> using a
translation-table which you can access with the <CODE>getkeycodes(8)</CODE>
and <CODE>setkeycodes(8)</CODE> utilities. You will only need to look at that
if you have some sort of non-standard (or programmable ?) keys on your
keyboard. AFAIK, these keycodes are the same among a set of keyboards
sharing the same hardware, but differing in the symbols drawn on the
keys.
</LI>
<LI> a mechanism turning <EM>keycodes</EM> into <EM>characters</EM> using a
<EM>keymap</EM>. You can access this <EM>keymap</EM> using the
<CODE>loadkeys(1)</CODE> and <CODE>dumpkeys(1)</CODE> utilities.</LI>
</UL>
</P>
<P>The keyboard driver can be in one of 4 modes (which you can access
using <CODE>kbd_mode(1)</CODE>), which will influence what type of data
applications will get as keyboard input:</P>
<P>
<UL>
<LI> the scancode (<CODE>K_RAW</CODE>) mode, in which the application gets
scancodes for input. It is used by applications that implement their
own keyboard driver. For example, X11 does that.
</LI>
<LI> the keycode (<CODE>K_MEDIUMRAW</CODE>) mode, in which the application
gets information on which keys (identified by their keycodes) get
pressed and released. AFAIK, no real-life application uses this mode.
</LI>
<LI> the ASCII (<CODE>K_XLATE</CODE>) mode, in which the application
effectively gets the characters as defined by the <EM>keymap</EM>, using
an 8-bit encoding. In this mode, the <CODE>Ascii_0</CODE> to <CODE>Ascii_9</CODE>
keymap symbols allow to compose characters by giving their decimal
8bit-code, and <CODE>Hex_0</CODE> to <CODE>Hex_F</CODE> do the same with (2-digit)
hexadecimal codes.
</LI>
<LI> the Unicode (<CODE>K_UNICODE</CODE>) mode, which at this time only
differs from the ASCII mode by allowing the user to compose UTF8
unicode characters by their decimal value, using Ascii_0 to Ascii_9
(who needs that ?), or their hexadecimal (4-digit) value, using Hex_0
to Hex_9. A keymap can be set up to produce UTF8 sequences (with a
<CODE>U+XXXX</CODE> pseudo-symbol, where each <CODE>X</CODE> is an hexadecimal digit),
but be warned that these UTF8 sequences will also be produced even in
ASCII mode. I think this is a bug in the kernel.</LI>
</UL>
</P>
<P><B>BE WARNED</B> that putting the keyboard in <CODE>RAW</CODE> or <CODE>MEDIUMRAW</CODE>
mode will make it unusable for most applications. Use <CODE>showkey(1)</CODE> to
get a demo of these special modes, or to find out what
scancodes/keycodes are produced by a specific key.</P>
<H2><A NAME="ss5.2">5.2</A> <A HREF="lct.html#toc5.2">See also</A>
</H2>
<P><CODE>keytables(5)</CODE>, <CODE>setleds(1)</CODE>, <CODE>setmetamode(1)</CODE>.</P>
<HR>
<A HREF="lct-6.html">Next</A>
<A HREF="lct-4.html">Previous</A>
<A HREF="lct.html#toc5">Contents</A>
</BODY>
</HTML>