James K. Lowden <jklowden@schemamania.org> typed:
: On Wed, 1 Oct 2003, Geoff Wing <mason@primenet.com.au> wrote:
: 
: 1.  /netbsd reads the raw scancode from the keyboard with wskbd(4).
: 2.  X multiplexes wsdbd?  
: 3.  xterm reads wsdbd and converts the value to a key sequence.  Which key
: sequence depends on what terminal it's emulating.  
: 4.  An application, frequently the shell, reads the key sequence from the
: tty interface, usually in raw mode.  

Basically, something like:

2) X input:
    X directly connects to a wscons tty - you can see this.  Find the pid of
    the "xfree86" process, then do "fstat -p <pid>" on it.  One will be ttyE#
    where # is a number.  The tty opened is not put into canonical mode.

   X output:
    on every keypress/keyrelease the X server puts the event containing
    keycode, time, focused window, etc. into its event queue.

3) xterm (or other X program) input:
    reads over connection (to X server) to obtain key related events (for
    its window set) from the event queue, then normally will convert those
    keycodes to Keysym format.  Doing this includes alterations according
    to keymap (see xmodmap(1)).  It then uses the Keysym codes to
    determine what keys have been pressed.
    
   xterm output:
    the xterm will communicate via a pty/tty interface to its client - this
    is the tty interface you see on the client via stty.
    The xterm converts all its input Keysyms into byte codes and writes
    them to the tty.  If the delete key has been pressed and the xterm
    wants this to be a sequence of several bytes then it writes that
    multi-byte sequence to the tty 

4) the shell (or application) input:
    the shell reads from the tty interface.  When it's ready for normal
    input it puts the tty into noncanonical (a.k.a. raw) mode and reads
    bytes from the tty stream.  When it's executing a command it puts
    the tty back into canonical (a.k.a. cooked) mode - and yes, this is
    one occasion where the tty control characters can be used and have
    effect.  However, when the shell is ready again it puts the tty
    into raw mode and reads anything awaiting and processes it the same
    as if it had been received in raw mode.
 
The termcap/terminfo interface is the base method that the application
should use to determine which sequence the xterm should send for each
special key.  Several shells are more lenient and allow users who
misconfigure their TERM settings to still have things work, e.g. by
allowing both ^H and ^? to have the same effect.  Or by allowing arrow
keys (which can produce different sequences in different modes) to work
in each mode.

: Following your suggestion and interpreting some of what I found in
: http://www.ibb.net/~anne/keyboard/keyboardprev.html, I got my delete key
: to do something useful in bash, where I need it most.  Mine now looks like
: this: : : "\e[3~": delete-char		# [delete]
: "\e[H": beginning-of-line	# [home]
: "\e[F": end-of-line		# [end]
: 
: IMHO, these bindings and their equivalents for editline and vi should be
: standard issue in NetBSD.

Not really.  There is no total agreement over what some of these special
keys should produce.  Have a look at what (historically) different terminals
produce for the backspace key: 
% fgrep kb= /usr/share/misc/termcap | sed 's,^.*\(kb=[^:]*\).*$,\1,' | sort -u

(or for the delete key, change the two "kb"s to "kD"s).  Most terminals now
have BS with either ^H or ^?  (and control-BS toggles to the other) as the
most popular terminal types in effect produced a defacto standard.

: [1] Curiously, it seems readline (which bash uses, as you know) has no
: systemwide configuration file.  It's ~/.inputrc or nothing (well, or
: read.c).  Many web pages refer to /etc/inputrc, but it's definitely not in
: bash 2.05.  I guess the theory is that it's enough to export INPUTRC in
: /etc/profile.  

I guess some base systems have "$include /etc/inputrc" in the skeleton files
for each users ~/.inputrc

Regards,
-- 
Geoff Wing : <gcw@pobox.com>
Rxvt Stuff : <gcw@rxvt.org>
Zsh Stuff  : <gcw@zsh.org>