Re: key codes table.

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

Eventually Ray is going to regret asking me these questions ...

On Feb 26,  9:34pm, Ray Andrews wrote:
}
} 'Available' key combinations on a '101' PC keyboard attached to a PC 
} running 'zsh' under xfce4 under Debian Linux (I don't know who's 'in 
} charge').

Unfortunately the set of key sequences you've listed here is likely
very specific to the environment you just described.  As you've noticed, 
it's not even the same for the console terminals on the same OS.

For example my PC101 keyboard on CentOS / Gnome sends ^[OQ, not ^[[[B.
On Ubuntu 12.04 it also sends ^[OQ.

} 'Alt+Function' keys switch terminals. Perhaps the 'Meta' key would do 
} more, but this is with a 101 KB.

Whether the Alt and Meta keys do something is also controllable via a
number of different mechanisms which may include X resources and your
language environment.

} Interesting that there are far more 
} combinations available in DOS, such as Ctrl+Function -- all available in 
} DOS, none of them available in Linux, so it seems.

If you mean Ctrl+F1, Ctrl+F2, etc., those are certainly available "in
Linux" because for Ctrl+F2 I get ^[O5Q (CentOs) or ^[O1;5Q (Ubuntu)
[and so on for other Ctrl+Fn keys].  (Actually this may be an xterm vs.
gnome-terminal difference instead of CentOS vs. Ubuntu.)

Do you begin to see why we don't bother attempting to create a static
table of all this?

} None of the triple 
} key combinations (eg. 'Ctrl+Alt+Up') produced any unique codes

Ctrl+Alt combinations are often grabbed by GUI management layers (as
are Meta combinations); more about this in a bit ...

} anomalies: '^[[22' '^[[27' '^[[30' are 'missing', you hafta wonder why 
} those numbers were skipped. (Which is to say that you might expect 'F11' 
} to be '^[[22' not '^[[23'.)

Could be an artifact of some other (possibly historical/disused) keyboard
layout such as the Sun keyboard that zkbd partly supports.  Could even be
related to the wiring of the circuit board in some keyboard from the 80s
that became a defacto standard.  A lot of this stuff was invented when
most Unix keyboards were an integral part of the terminal device and
there was no such thing as separate, independent monitor and keyboard.

} A-Alt        = '^[a'
} A-Alt-Ctrl   = '^[^A'
} A-Alt-Shift  = '^[A'

Note that the effect of Alt prefixing the key with ESC is one of those
things I mentioned about that may depend on your language environment.
It is equally likely that those combinations send single 8-bit chars
equivalent to $'\Ma' $'\M\Ca' and $'\MA' respectively.

Or the Meta key might do that instead of the Alt key.
 
} Don't forget that:
} 
} /-Shift-Ctrl = Bksp      = '^?'

Actually that is ASCII DELete not Backspace.  Backspace is ^H ... but 
of course the Del key might send any of ^? or ^H or ^[[3~ etc., and
the key labeled Backspace often sends ^?.

} Where is it written that 'Ctrl-Bksp' gives one code at console, another 
} in in xterm?
} 
} Are these assignments changeable?
} 
} Who designed all this, and what were they thinking at the time?
} 
} Why is it 'Alt-Function' to change terminals *at* a terminal, but 
} 'Alt-Ctrl-Function' to change *to* a terminal from GUI?
} 
} How/where is 'Alt-Ctrl-Delete' defined?

All of these have related answers.

Consider all the layers that a key press has to pass through to reach
your shell or other program running in your xterm:

- Circuit board in the keyboard itself
- Motherboard or graphics card hardware
- BIOS
- Operating system device driver
- Input event device
  [<
- X server event handler
- Session manager
- Desktop manager
- Window manager
- Terminal emulator
  >]
- (Pseudo-) TTY device
- Kernel I/O layer
- User-space system call interface

Everything in [< here >] is replaced by the virtual console manager
when you are not using a GUI.  That is the background for both of
your questions about why xterm and console behave differently.  It's
a bit more complicated than that because the GUI usually occupies
one of the virtual consoles, but this is windy enough already.

(In DOS, roughly speaking, things go directly from the OS driver to
the I/O layer and skip everything I listed in between, which is why
there is so little variation or complexity in behavior.)

In many cases there's also a special language-dependent keyboard
input layer in there somewhere, to handle ideogram compositing in
Chinese or translating an English keyboard to input in Cyrillic, or
what have you.

Each of these layers gets a chance to handle the event before the
one below it may do so.  Ctrl-Alt-Del is usually handled in the BIOS
or the OS device driver.  Caps Lock is a hardware thing on some old
keyboards and sent no event to the motherboard.  Key repeat is often
a hardware thing but is frequently emulated (or mediated) by one of
the software layers instead.  Ctrl-Alt-Fn is handled by the X server
(usually; could be one of the other manager layers) whereas Alt-Fn
is handled by the virtual console manager.  Etc.

There are two other things about the stuff [< here >].  First, each
above the terminal emulator sees a separate event for every key on
your keyboard; there isn't a single event for e.g. "Ctrl+Alt+F7": 

- Ctrl press
- Alt pres
- F7 press
- F7 release
- Alt release
- Ctrl release

which of course can happen in a variety of orders depending on your
typing style and speed, though at least the first two must precede
the third.  Each layer can choose to act (or not) on each event, and
to pass along (or not) (or both) each event, though passing along a
"press" without also passing "release" is bad form (happens sometimes
though, often by accident).

The terminal emulator gets sent the events that trickle through the
layers above it, and keeps track of state so that it can send the key
(or key sequence) as one "event" to the TTY device at the time of the
appropriate "press" (or sometimes release) event, and then unwind that
state as the rest of the release events arrive.

Second, in a GUI environment there's a lot more meaning associated
with those events than just keyboard input.  Ctrl with a mouse click
or drag may mean something, the pointer position at the instant the
key is pressed is important, etc., etc.  Everything up and down the
stack of layers has to cooperate.

So "who designed this" is "different people at different times" and
"what were they thinking?" is generally "what works best for user
control of each layer he's allowed to control, without screwing up
all the old stuff that everyone is already familiar with?"

Of course in the case of terminal emulators they were also thinking
"how do I make this work as much like an <thingus> terminal as it
can while still playing nicely with everything else?"

As for whether the assignments are changeable: yes!  At effectively
every layer from the session manager down to the terminal emulator;
though exactly what they are allowed to do at each layer varies,
and you might have to change several layers to get a particular key
combination to be visible to the terminal emulator, which may break
something else in ways you don't expect.

Does that clear things up? :-)