455 lines
7.9 KiB
HTML
455 lines
7.9 KiB
HTML
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>How Keys Are Turned Into Actions</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.63
|
|
"><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
|
|
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"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
></TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="why.html"
|
|
>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</A
|
|
></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
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="intro.html"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="why.html"
|
|
>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
|
|
> |