Next
Previous
Contents
See also section
Some Details on How Terminals Work
Each terminal is connected to a serial port on the host computer
(often just a PC). The ports have names/numbers. The first few are: tts/0
(or ttyS0), tts/1 (or ttyS1), tts/2 (or ttyS2) etc.
These are represented by special files found in the /dev (device)
directory. tts/0 (or ttyS0) corresponds to COM1 in DOS or Windows.
tts/1 (or ttyS1) is COM2, etc. See
Terminal Special Files for details on these and related "devices".
When the host computer starts up it runs the program getty. The
getty program runs the "login" program to log people in. See
Getty (used in /etc/inittab). A "login:" prompt
appears on the screen. People at the terminals log in (after giving
their passwords) and then have access to the computer. When it's time
to shut the terminal down, one normally logs out and turns the
terminal off. See
Login Restrictions
regarding restricting logins (including allowing the root user to log
in at terminal).
If one watches someone typing at a terminal, the letters one types
simultaneously appear on the screen. A naive person might think that
what one types is being sent directly from the keyboard to the screen
with a copy going to the computer (half-duplex like, see next
paragraph). What is usually going on is that what is typed at the
keyboard is directly sent only to the host computer which in turn
echoes back to the terminal each character it receives (called
full-duplex). In some cases (such as passwords or terse editor
commands) the typed letters are not echoed back.
Full-duplex means that there are two (dual) one-way communication
links. Full-duplex is the norm for terminals. Half-duplex is half of
a duplex, meaning that there is only a single one-way communication
link. This link must be shared by communications going in both
directions and only one direction may be used at a time. In this case
the computer would not be able to echo the characters you type (and
send to it) so the terminal would need to also send each character you
type directly to the terminal screen. Some terminals have a
half-duplex mode of operation which is seldom used.
The image on a CRT tube will fade away almost instantly unless it
is frequently redrawn on the screen by a beam of electrons shot onto
the face of the tube. Since text sent to a terminal needs to stay
on the screen, the image on the screen must be stored in the memory
chips of the terminal and the electron beam must repeatedly scan the
screen (say 60 times per second) to maintain the image. See
Terminal Memory Details for more details.
The terminal is under the control of the computer. The computer
not only sends the terminal text to display on the screen but also
sends the terminal commands which are acted on. These are
Control Codes (bytes) and
escape sequences. For example, the CR (carriage return)
control code moves the cursor to the left hand edge of the screen. A
certain escape sequence (several bytes where the first byte is the
"escape" control code) can move the cursor to the location on the
screen specified by parameters placed inside the escape sequence.
The
first terminals had only a few such
commands but modern terminals have hundreds of them. The appearance
of the display may be changed for certain regions: such as bright,
dim, underline, blink, and reverse video. A speaker in a terminal
can "click" when any key is pressed or beep if a mistake has occurred.
Function keys may be programmed for special meanings. Various fonts
may exist. The display may be scrolled up or down. Specified parts
of the screen may be erased. Various types of flow control may be
used to stop the flow of data when bytes are being sent to the
terminal faster than the terminal can handle them. There are many
more as you will see from looking over an advanced terminal manual or
from the Internet links
Esc Sequence List
While terminals made for the US all used the same ASCII code for
the alphabet (except for IBM terminals which used EBCDIC), they
unfortunately did not all use the same escape sequences. This
happened even after various ANSI (and ISO) standards were established
since these standards were never quite advanced enough. Furthermore,
older terminals often lacked the capabilities of newer terminals.
This might cause problems. For example, the computer might send a
terminal an escape sequence telling it to split the screen up into
two windows of specified size, not realizing that the terminal was
incapable of doing this.
To overcome these problems a database called "termcap" (meaning
"terminal capabilities") was established. Termcap was later
superceded by "terminfo". This database resides in certain files on
the computer and has a section of it (sometimes a separate file) for
each model of terminal. For each model (such as VT100) a list of
capabilities is provided including a list of certain escape sequences
available. For example blink=\E5m means that to make the cursor start
blinking the terminal must be sent: Escape 5 m. See Section
Termcap and Terminfo (detailed) for more
details. Application programs may utilize this database by calling
certain C-Library functions. One large set of such programs (over
200) is named "ncurses" and are listed in the manual page for
"ncurses" which comes with a developer's ncurses package. There is
also a NCURSES-programming-HOWTO.
The environment variable TERM is the type of terminal Linux thinks
you are using. Most application programs use this to look up the
capabilities in the terminfo database so TERM needs to be set
correctly. But there is more to a correct interface than the
computer knowing about the capabilities of the terminal.
For bytes to flow from the computer to the terminal the terminal must
be set to receive the bytes at the same baud rate (bits per second) as
they are sent out from the terminal. If the terminal is set to receive at
19,200 baud and the computer sends out characters at 9600 baud, only
garbage (or perhaps nothing) will be seen on the screen. One selects
the baud rate for a terminal (as well as many other features) from the
terminals "set-up" menus at the terminal. Most terminals have a large
number of options in their "set-up" menus (see
Terminal Set-Up (Configure) Details).
The computer serial port has options also and these options must be
set up in a compatible way (see
Computer Set-Up (Configure) Details.
Most terminals today have more than one emulation (personality or
"terminal mode"). The terminal model numbers of terminals formerly
made by DEC (Digital Equipment Corporation now Compaq) start with VT
(e.g. VT100). Many other terminals which are not VT100 may be set up
to emulate a VT100. Wyse is a major terminal manufacturer and most of
their terminals can emulate various DEC terminals such at VT100 and
VT220. Thus if you want to, say, use a VT320 terminal you may either
use a real VT320 in "native" personality or possibly use some other
terminal capable of emulating a VT320.
The "native" personalities usually have more capabilities so, other
things being equal, "native" is usually the best to use. But other
things may not be equal. Since the Linux console emulates a VT102 it
you may want to have a terminal emulate this (or something close to it
such as VT100). This will help insure that some programs that may not
handle terminals properly will still work OK on your terminal. Some
programs will assume that you are using a VT102 if the program can't
find a terminfo for your terminal (or can't find a certain
capability). Thus the failure of a program to work correctly with
your non-vt102 terminal may well be your fault if you don't provide a
good terminfo file for your terminal. Using "native" and then
reporting any bugs will help discover and fix bugs which might not
otherwise get detected.
The most common type of emulation is to use a PC like it was a vt100
terminal (or the like). Programs loaded into the PC's memory do the
emulation. In Linux (unless you're in X Window) the PC monitor
(called the console) emulates a terminal of type "Linux" (close to
vt100). Even certain windows within X Window emulate terminals. See
Terminal Emulation.
On a PC, the monitor is normally the console. It emulates a
terminal of type "Linux". One logs on to it as a virtual terminal.
See
The Console. It receives messages
from the kernel regarding booting and shutdown progress. One may have
the messages that normally go to the console, go to the terminal. To
get this you must manually patch the kernel, except that for kernel
2.2 (or higher) it is a "make config" option. See
Make a Serial Terminal the Console.
Next
Previous
Contents
|