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 terminal. 

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 device 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)). 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 predefined 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 terminal manager take care of restoring the device.  Process control mode processes will be sent a signal that they have specified (acqsig) when they become the active VT.  The process 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 protocol. 

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 argument to the ioctl is a pointer to a long.  The long will be filled in with the number of the first available 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 argument to the ioctl is the address of the following structure, as defined in <sys/vt.h>. 

struct vt_mode {
charmode;/* VT mode */
charwaitv;/* if non-zero, hang on writes when
not active */
shortrelsig;/* signal to use for release request */
shortacqsig;/* signal to use for display acquired */
shortfrsig;/* signal to use for forced release */
}

/* Virtual Terminal Modes */
#defineVT_AUTO0 /* automatic VT switching */
#defineVT_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 communicate 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. 

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 {
ushortv_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 structure 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 INTER­ACTIVE 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 EINVAL, 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. 

\*U  —  Version 1.0