<HTML
><HEAD
><TITLE
>How Keys Are Turned Into Actions</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
"><LINK
REL="HOME"
TITLE="Linux Backspace/Delete mini-HOWTO"
HREF="index.html"><LINK
REL="PREVIOUS"
TITLE="Introduction"
HREF="intro.html"><LINK
REL="NEXT"
TITLE="Why It Doesn't (Always) Work"
HREF="why.html"></HEAD
><BODY
CLASS="SECT1"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Linux <B
CLASS="KEYCAP"
>Backspace</B
>/<B
CLASS="KEYCAP"
>Delete</B
> mini-HOWTO</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="intro.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="why.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="ACTIONS">2. How Keys Are Turned Into Actions</H1
><P
>When a key is pressed on the keyboard, a number of hardware and
software components cooperate so as to guarantee that the intended meaning
of the key (e.g., emitting a certain character) matches the actual
behaviour of the key. I will concentrate on the software side (as our
control on the hardware part is nonexistent), and in particular, for the
time being, on the events related to console output.</P
><P
></P
><OL
TYPE="1"
><LI
><P
>Hitting a key causes raw keyboard <I
CLASS="FIRSTTERM"
>scancodes</I
>
to be generated; these scancodes are then transformed in a
<I
CLASS="FIRSTTERM"
>keycode</I
>. On an i386 system, usually the key
<B
CLASS="KEYCAP"
>Backspace</B
> emits <SPAN
CLASS="KEYCODE"
>14</SPAN
> and the key
<B
CLASS="KEYCAP"
>Delete</B
> emits <SPAN
CLASS="KEYCODE"
>111</SPAN
>.</P
></LI
><LI
><P
>The keycodes are translated by the keyboard library into a
<I
CLASS="FIRSTTERM"
>keyboard symbol (keysym)</I
> using the keyboard
definition loaded by the user. If you look into your keyboard database
(e.g., in <TT
CLASS="FILENAME"
>/lib/kbd/</TT
>), you'll discover several
definitions for different computers, different layouts and possibly
different interpretations of the same keys (e.g., one could desire that
the two <B
CLASS="KEYCAP"
>Alt</B
> keys really behave as distinct
modifiers). The Linux console keyboard layout assigns keysym
<SPAN
CLASS="KEYSYM"
>Delete</SPAN
> to keycode 14 and keysym
<SPAN
CLASS="KEYSYM"
>Remove</SPAN
> to keycode 111. This may seem strange, but the
Linux console emulates a VT100 terminal, and this is the way things
work in that realm.<A
NAME="AEN77"
HREF="#FTN.AEN77"
>[1]</A
></P
></LI
><LI
><P
>Our journey has still to come to an end. Console applications
read <SPAN
CLASS="ACRONYM"
>ASCII</SPAN
> sequences, not keysyms. So the console
must read keysyms and translate them into <SPAN
CLASS="ACRONYM"
>ASCII</SPAN
>
sequences that suitably encode the keys. Of course, this operation must
be performed in a way that is understandable by applications. For
instance, on the Linux console the <SPAN
CLASS="KEYSYM"
>Delete</SPAN
> keysym is
mapped to the <SPAN
CLASS="ACRONYM"
>ASCII</SPAN
> code 127 (<SPAN
CLASS="SYMBOL"
>DEL</SPAN
>),
the <SPAN
CLASS="KEYSYM"
>Remove</SPAN
> keysym on a suitable escape sequence, and
the <SPAN
CLASS="KEYSYM"
>BackSpace</SPAN
> keysym to <SPAN
CLASS="ACRONYM"
>ASCII</SPAN
> code
8 (<SPAN
CLASS="SYMBOL"
>BS</SPAN
>).</P
></LI
><LI
><P
>Finally, we must in a sense roll back to what we had before and
translate the <SPAN
CLASS="ACRONYM"
>ASCII</SPAN
> sequences generated by each key
into a <I
CLASS="FIRSTTERM"
>key capability</I
>. This goal is reached by a
<I
CLASS="FIRSTTERM"
>terminal database</I
>, which contains, for each kind
of terminal, a reverse mapping from sequences of characters to key
capabilities (which are essentially a subset of the keysyms).<A
NAME="AEN95"
HREF="#FTN.AEN95"
>[2]</A
></P
><DIV
CLASS="NOTE"
><P
></P
><TABLE
CLASS="NOTE"
WIDTH="90%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>Unfortunately, there are two <SPAN
CLASS="QUOTE"
>"standard"</SPAN
> terminal
databases, <SPAN
CLASS="APPLICATION"
>termcap</SPAN
> and
<SPAN
CLASS="APPLICATION"
>terminfo</SPAN
>. Depending on your distribution,
you could be using either one of them, or the database could even
depend on the application. Our discussion will concentrate on the
more modern <SPAN
CLASS="APPLICATION"
>terminfo</SPAN
> database, but the
suggested fixes take both into consideration. </P
></TD
></TR
></TABLE
></DIV
><P
>For instance, on the Linux console <B
CLASS="KEYCAP"
>F1</B
> generates
an escape followed by <TT
CLASS="LITERAL"
>[[A</TT
>, which can be translated
to the capability <TT
CLASS="LITERAL"
>key_f1</TT
> by looking into the
terminal-database entry of the console (try <B
CLASS="COMMAND"
>infocmp
linux</B
> if you want to have a look at the entry). A very good
and thorough discussion of terminal databases can be found in
<SPAN
CLASS="ACRONYM"
>GNU</SPAN
>'s <SPAN
CLASS="APPLICATION"
>termcap</SPAN
>
manual. Usually Linux applications use the newer
<SPAN
CLASS="APPLICATION"
>terminfo</SPAN
> database, contained in the
<SPAN
CLASS="APPLICATION"
>ncurses</SPAN
> package.</P
><P
>Maybe at this point not surprisingly, the Linux console terminfo
entry maps <SPAN
CLASS="SYMBOL"
>DEL</SPAN
> to the <TT
CLASS="LITERAL"
>kbs</TT
>
(backspace key) capability, and escape followed by
<TT
CLASS="LITERAL"
>[3~</TT
> to the <TT
CLASS="LITERAL"
>kdch1</TT
>
(<SPAN
CLASS="QUOTE"
>"delete-one-char"</SPAN
> key) capability. Even if you could
find strange that the <B
CLASS="KEYCAP"
>Backspace</B
> key emits a <SPAN
CLASS="SYMBOL"
>DEL</SPAN
>,
the terminal database puts everything back into its right place, and correctly
behaving applications will interpret <SPAN
CLASS="SYMBOL"
>DEL</SPAN
> as the capability
<TT
CLASS="LITERAL"
>kbs</TT
>, thus deleting the character to the left of the cursor.</P
></LI
></OL
></DIV
><H3
CLASS="FOOTNOTES"
>Notes</H3
><TABLE
BORDER="0"
CLASS="FOOTNOTES"
WIDTH="100%"
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN77"
HREF="actions.html#AEN77"
>[1]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>This claim has been
asserted/disputed several times commenting this document. If you have
any definitive information on this subject, please write me.</P
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN95"
HREF="actions.html#AEN95"
>[2]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>Some programs rely on the terminal driver for input line editing,
such as deleting characters or words. With <B
CLASS="COMMAND"
>stty</B
>, you
can tell the terminal driver what character it should use to delete the
character to the left of the cursor (the <I
CLASS="FIRSTTERM"
>erase</I
>
character). You can check your current settings with <B
CLASS="COMMAND"
>stty
-a</B
> and set them with <B
CLASS="COMMAND"
>stty erase
<TT
CLASS="REPLACEABLE"
><I
>character</I
></TT
></B
>.</P
></TD
></TR
></TABLE
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="intro.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="why.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Introduction</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
> </TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Why It Doesn't (Always) Work</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
