There are several things about terminals that are managed inside the kernel, such as keyboard signals (mapping e.g. Ctrl+Z to SIGSTOP), managing foreground and background process groups, an extremely crude line edition mechanism, sending SIGHUP when the terminal goes away, and other niceties.
With a hardware terminal, the terminal device sits between the application and the hardware. The kind of terminal device depends on the kind of hardware, for example (on Linux) /dev/tty1 for a PC keyboard and screen, /dev/ttyS0 for a terminal connected over a serial line, /dev/ttyUSB0 for a terminal connected over USB, etc.
+-------------+ +-----------------+ +-------------+
| text mode | | kernel | | peripheral |
| application |<------->| e.g. /dev/ttyS0 |<------->| e.g. on a |
| | | | | serial port |
+-------------+ +-----------------+ +-------------+
With a terminal emulator, the principle is the same, with the connection still going through a kernel driver, but what's at the other end is also a process.
+-------------+ +-----------------+ +-------------------+
| text mode | | kernel | | terminal emulator |
| application |<------->| /dev/pts/* |<------->| e.g. xterm, sshd, |
| | | | | screen, ... |
+-------------+ +-----------------+ +-------------------+
Xterm, telnetd¹, sshd and the like are not (directly) connected to any hardware. When you type a key on a keyboard, the information goes through the keyboard (the physical device) to the keyboard driver inside the kernel which then relays it to a process that's listening on the keyboard device. If you're in a graphical session, that process is an X server which then relays the information to the process whose window is focussed. Conversely, when a program running inside xterm produces output, xterm transforms this into an order for the X server to display certain characters in a certain font at a certain position. There is no hardware involved anywhere near the process that's processing the input or producing the output, and possibly none at all (e.g. if the xterm window is not visible on the screen, or at least none locally if the terminal is provided by a telnet or ssh server).
¹ The terminal is on the remote (server) side.
The manual page is not clear, but reading the source code helps:
- take a look at input-keys.c, and you will see the keys, listed in a table.
- the table is used in the same file, in
input_key
- near the top of the file, there's a comment:
/*
* This file is rather misleadingly named, it contains the code which takes a
* key code and translates it into something suitable to be sent to the
* application running in a pane (similar to input.c does in the other
* direction with output).
*/
Your shell is the application that the comment refers to.
The terminal-overrides is used to modify the terminal description which tmux reads, to allow you to work with configurations (of the external "real" terminal) which do not match the terminal description:
tmux translates keys into its own set of escape sequences (matching the ones in screen, with the exception that it adds the xterm-keys option). The comment at the top of window.c summarizes this:
* A pane has two buffers attached, these are filled and emptied by the main
* server poll loop. Output data is received from pty's in screen format,
* translated and returned as a series of escape sequences and strings via
* input_parse (in input.c). Input data is received as key codes and written
* directly via input_key.
The manual page says
default-terminal terminal
Set the default terminal for new windows created in this session - the default value of the TERM environment variable. For tmux to work correctly, this must be set to ‘screen’, ‘tmux’ or a derivative of them.
The reason for the restriction is that there's no way to customize the data in input-keys.c in the way you would like.
Best Answer
DEC VTs represent function keys and various cursor and editing keys with a control sequence named DECFNK, which is CSI followed by one or two parameters followed by
~. The first parameter is the function key number. The second parameter indicates active modifier key states.As far as DECFNK is concerned, there can be up to 20 function keys. The DECFNK codes for function keys 1 to 20 are well-defined and documented. There were, after all, physically 20 function keys on the LK keyboards. (Even if several function keys usually did not, they could potentially all generate DECFNK sequences, and the sequences are in the DEC doco.) Here's an LK401 keyboard for a DEC VT420:
As you can see in your table, the emulators that produce the original DECFNK sequences emit DECFNK 11 to DECFNK 34 for these 20 keys. (Some of the DECFNK numbers are skipped. Interestingly, the skipped numbers correspond to the physical spaces between the key groups of the function key row on the keyboard.)
Where things get complex is where the PC and XENIX were introduced. In the world of the IBM PC, and in particular the PC 3270, there were 24 function keys on the Model F keyboards. The PC/AT's Enhanced keyboard had 12 function keys, half that. Here is a 3270 Model F keyboard:
Terminal emulation conventions arose that the function keys from F13 to F24 could be accessed from a PC/AT keyboard by using combinations of modifiers. With the four combinations of ⎈ Control and ⇧ Level 2 Shift, the mere 12 function keys on an Enhanced keyboard could be made to simulate 48 function keys. This was the case for the XENIX console, which generated 48 distinct control sequences.
You will observe in the other columns of that table that that is what is happening. The control sequences for (say) F6, F18, F30, and F42 are all DECFNK 17 with different values for the modifier bitflags in the second parameter.
Also observe that F1 to F5 are not DECFNK control sequences in those same columns. This is again down to emulator conventions on PC keyboards. On the DEC LK keyboards, F1 to F5 did have assigned DECFNK sequences and could generate them, but usually operated in a "local" mode where they did not generate input to the host. Emulators did not need to generate these DECFNK sequences and emulate F1 to F5, because few to no applications relied upon these keys as a consequence; but emulators conversely did need to emulate a set of PF1 to PF4 keys that were on the calculator keypad in an actual DEC keyboard, but that PC keyboards did not have. These keys did not generate DECFNK sequences, and weren't true function keys. They generated SS3 control sequences, like the other calculator keys.
(Some of the SS3 sequences are malformed. "SS" stands for "Single Shift" and such shifts apply to a single following character. The XTerm control sequences that append modifier parameters to SS3 are not in fact correctly formed SS3 sequences. Real DEC terminals did not work this way. Modifiers were not reported for calculator key control sequences.)
This explains how the function key control sequence set for emulated terminals can go as high as 48 function keys. To explain 64 control sequences, one simply needs to notice the modifier parameter in the DECFNK sequences. For the additional 12 control sequences it is
3, which denotes the ⎇ Alt modifier.In fact, there are 8 possible combinations of ⎈ Control, ⇧ Level 2 Shift, and ⎇ Alt; the three modifiers recognized by the DEC VT control sequence protocol. There can thus be 96 different DECFNK control sequences per these terminal emulator conventions from a PC/AT Enhanced keyboard, and 160 from a DEC LK keyboard.
Further reading