vt(7) INTERACTIVE UNIX System vt(7)
NAME
vt - virtual terminal management
DESCRIPTION
The virtual terminal (VT) device driver is a layer of
management functions that provides the facilities to support
and switch between up to eight screen faces on each physical
device. Terminal or display device drivers that have been
written to take advantage of this facility can therefore
present multiple VTs on a single physical device. The
correspondence between physical and virtual terminals is
determined using the minor device number of the physical
device, with the bottom five bits selecting the physical
device and the top three bits selecting the virtual termi-
nal.
Virtual terminals are accessed in exactly the same way as
any other device. The open(2) system call is used to open
the virtual terminal, and read(2), write(2), and ioctl(2)
are used in the normal way and support all the functionality
of the underlying device. In addition, some VT-specific
ioctls are provided as described below.
Virtual terminals provide the link between different screen
faces and the device. The virtual terminal that corresponds
to the currently visible screen face is said to be the
active virtual terminal. The active VT is the one that
input from the device will be directed to, and any device-
specific modes that can change on a per VT basis will be set
to the characteristics associated with the active VT.
Open virtual terminals on a device are placed on a ``ring,''
with the active VT always being the VT on the top of the
ring. The ring can be cycled through via a ``hot key'' that
is specific to the underlying device driver. The first open
of a VT causes it to be placed at the top of the ring and
become the active VT. The last close on a VT causes it to
be removed from the ring, and if this was the active VT, the
previous VT on the ring becomes the active one.
Virtual terminal switching can be done in two different
modes: automatically (VT_AUTO) on receipt of a ``hot key,''
or under control of the process owning the VT (VT_PROCESS).
In the first case, the process associated with the VT knows
nothing about the switch, and saving and restoring the dev-
ice are handled entirely by the underlying device driver and
the virtual terminal manager. So that the ordinary process
need not be concerned with it, this is the default VT mode;
switching will be done automatically.
In process-controlled switch mode, when a switch ``hot key''
is sent, the process owning the VT is sent a signal (relsig)
that it has specified to the VT manager (see sigset(2)).
Rev. 1.2 Page 1
vt(7) INTERACTIVE UNIX System vt(7)
This signal requests the process to release the physical
device. The VT manager then awaits the VT_RELDISP ioctl
from the process. If the process refuses to release the
device (in which case the switch does not occur), it does a
VT_RELDISP ioctl with an argument of 0 (zero). If a prede-
fined time limit expires before the VT_RELDISP ioctl is
received from the process owning the VT, the VT manager
behaves as if an ioctl indicating refusal was received. If
the process desires to release the device, it should save
the device state (keyboard, display, and I/O registers) and
then do the VT_RELDISP ioctl with an argument of 1. At this
time the switch will occur.
The ring of active VTs can contain intermixed auto mode and
process control mode VTs. When an auto mode process becomes
active, the underlying device driver and the virtual termi-
nal manager take care of restoring the device. Process con-
trol mode processes will be sent a signal that they have
specified (acqsig) when they become the active VT. The pro-
cess should restore the device state (keyboard, display, and
I/O registers) and then do the VT_RELDISP ioctl with an
argument of VT_ACKACQ. This completes the VT switching pro-
tocol.
Some device drivers may support a forced switch mode, in
which case an alternate hotkey sequence will cause the
driver to force a switch to the next VT even if a normal
switch is refused. The driver does the forced switch and
the VT manager signals the VT that it has been forced out.
Ioctl Calls
The following ioctls apply to any device that supports VTs.
VT_OPENQRY
This call is used to find an available VT. The argu-
ment to the ioctl is a pointer to a long. The long
will be filled in with the number of the first avail-
able VT that no other process has open (and hence, is
available to be opened). If there are no available
VTs, then -1 will be filled in.
VT_GETMODE
This call is used to determine what mode the VT is
currently in, either VT_AUTO or VT_PROCESS. The argu-
ment to the ioctl is the address of the following
structure, as defined in <sys/vt.h>.
struct vt_mode {
char mode; /* VT mode */
char waitv; /* if non-zero, hang on writes when
not active */
short relsig;/* signal to use for release request */
short acqsig;/* signal to use for display acquired */
Rev. 1.2 Page 2
vt(7) INTERACTIVE UNIX System vt(7)
short frsig;/* signal to use for forced release */
}
/* Virtual Terminal Modes */
#define VT_AUTO0/* automatic VT switching */
#define VT_PROCESS1/* process controls switching */
The structure will be filled in with the current value
for each field.
VT_SETMODE
This call is used to set the VT mode. The argument to
the ioctl is a pointer to a vt_mode structure, as
defined above. The structure should be filled in with
the desired VT mode and whether or not to block on
writes when not active. If process-control mode is
specified then the signals that should be used to com-
municate with the process should be specified. If any
of the signals are not specified (value is zero), then
the default for that signal will be used (SIGUSR1 for
relsig and acqsig and SIGUSR2 for frsig).
VT_RELDISP
This call is used to tell the VT manager if the display
has been released or if the process has refused to
release the display. An argument of 0 indicates
refusal to release; an argument of 1 indicates that the
process has released the VT. This ioctl is also used
to indicate completion of acquiring the VT. This is
done by giving an argument of VT_ACKACQ.
VT_ACTIVATE
This call has the effect of making the VT specified in
the argument the active VT. The VT manager will cause
a switch to occur in the same manner as if a hotkey had
initiated the switch. If the specified VT is not open
or does not exist the call will fail and errno will be
set to ENXIO.
VT_WAITACTIVE
If the specified VT is already active, this call
returns immediately. Otherwise, it will sleep until
the specified VT becomes active, at which point it will
return. The argument to this ioctl is a pointer to the
vt_mode structure defined above. When this call is
made, the VT manager checks to see if there is already
a process with that VT. If there is not, it puts the
VT in active mode. Next, the VT manager checks to see
the VT passed by the arguments is already active. If
so, it returns the same VT. If there are no active VTs
available, it sets the VT flag to VT_WAITACT and sleeps
until a VT becomes active.
Rev. 1.2 Page 3
vt(7) INTERACTIVE UNIX System vt(7)
VT_GETSTATE
This call is used to obtain the active VT number and a
list of open VTs. The argument to this call is an
address to the following structure:
struct vt_stat {
ushort v_active,/* number of the active VT */
v_signal,/* signal type to be sent to open VTs */
v_state;/* count of openVTs. For every 1 in this
T field, there is an open VT */
}
and a pointer to the vt_mode structure defined above.
In this call, the VT manager first gets the number of the
active VT. Then it counts the number of open VTs in the
system and sets a 1 for each open VT in v_state. The VT
manager then transfers the information in structure vt_stat
passed by the user process.
VT_GETSIG
This call is used to send a signal to all open VTs.
The arguments to this call are a pointer to the struc-
ture vt_mode and a pointer to the structure vt_stat,
both defined above. In this call, the VT manager
checks whether the VT is open, and if it is, it sends
the signal given in the v_signal field of the vt_stat
structure.
FILES
/dev/vtxx
SEE ALSO
ioctl(2), sighold(2), signal(2), sigrelse(2), sigset(2) in
the INTERACTIVE SDS Guide and Programmer's Reference Manual.
WARNINGS
There is a potential for a race condition on a heavily
loaded system. When a process-control mode VT is sent the
release requested signal, it is possible that it may not
reply with a release ioctl before the internal timer expires
and refusal to switch is assumed. The switch request will
then be canceled and the VT will not switch screen faces.
This can be detected by the process attempting to release
the display. If the release ioctl fails and errno is EIN-
VAL, then the releasing process can assume that the switch
request was canceled.
ADDED VALUE
This entry, supplied by INTERACTIVE Systems Corporation, is
an extension of UNIX System V.
Rev. 1.2 Page 4