Ioctl Requests vt(7I) NAME virtual console - Solaris virtual console interface SYNOPSIS #include #include DESCRIPTION The virtual console, also known as virtual terminal (VT), device driver is a layer of management functions that provides the facilities to support and switch between multiple screen faces on a single physical device. Virtual consoles are accessed in exactly the same way as any other device. The open(2) system call is used to open the virtual console, 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 console provide the link between different screen faces and the device. The virtual console that corresponds to the currently visible screen face is said to be the active virtual console. 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. Virtual consoles are managed by the user by intercepting keyboard sequences (hot key). The sequence AltL (left "Alt" key) + F# (# is 1 to 12) is used to select virtual console 1-12, AltGraph (right "Alt" key) + F# (# is 1 to 12) is for virtual console 13-24; Alt + F1 chooses the system console (also known as virtual console 1); Alt + n or -> (directional arrow) selects the next virtual console in a circular ring fashion, and Alt + p or <- (directional arrow) changes to the previous virtual console in a circular fashion. And Alt + l or "up arrow" is for last used console. Virtual console 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 console 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 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 all 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 console 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. The IOCTLs of modify operations(VT_SETMODE, VT_RELDISP, VT_ACTIVATE, VT_WAITACTIVE, KDSETMODE) checks if the virtual console is the controlling tty of the calling process. If not, then enforces the sys_devices privilege. There is no controlling tty and privilege check for query/view operations. IOCTLS The following ioctls apply to any device that supports VTs. VT_AVAILABLE This call is used to query if if VT is available on the system. The argument to the ioctl is a pointer to an integer. If VT is available, the integer will 1, otherwise it will be 0. VT_OPENQRY This call is used to find an available VT. The argu- ment to the ioctl is a pointer to an integer. The integer 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 . struct vt_mode { char mode; /* VT mode */ char waitv; /* not used */ short relsig;/* signal to use for release request */ short acqsig;/* signal to use for display acquired */ short frsig;/* not used */ } /* Virtual console Modes */ #define VT_AUTO 0 /* automatic VT switching */ #define VT_PROCESS 1 /* 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. 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). 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. 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 { unsigned short v_active, /* number of the active VT */ v_signal, /* not used */ v_state; /* count of open VTs. For every 1 in this field, there is an open VT */ } 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. KDGETMODE This call is used to obtain the text/graphics mode associated with the VT. #define KD_TEXT 0 #define KD_GRAPHICS 1 KDSETMODE This call is used to set the text/graphics mode to the VT. KD_TEXT indicates that console text will be displayed on the screen with this VT. Normally KD_TEXT is combined with VT_AUTO mode for text console terminals, so that the console text display will automatically be saved and restored on the hot key screen switches. KD_GRAPHICS indicates that the user/application, usually Xserver, will have direct control of the display for this VT in graphics mode. Normally KD_GRAPHICS is combined with VT_PROCESS mode for this VT indicating direct control of the display in graphics mode. In this mode, all writes to this VT using the write system call are ignored, and the user is responsible for saving and restoring the display on the hot key screen switches. When the mode the active VT is changed from KD_TEXT to KD_GRAPHICS, or a VT of KD_GRAPHICS mode is made active from a previous active VT of KD_TEXT mode, the virtual console manager will initiate a KDSETMODE ioctl with KD_GRAPHICS as the argument to the underlying console framebuffer device indicating that current display is running into graphics mode. When the mode the active VT is changed from KD_GRAPHICS to KD_TEXT, or a VT of KD_TEXT mode is made active from a previous active VT of KD_GRAPHICS mode, the virtual console manager will initiate a KDSETMODE ioctl with KD_TEXT as the argument to the underlying console framebuffer device indicating that current display is running into console text mode. FILES /dev/vt/# SEE ALSO ioctl(2), signal(2), wscons(7D) NOTES By default, there is only five virtual console instances login prompts running on /dev/vt/# (# is 2 to 6) besides the system console running on /dev/console, so normally Xorg uses the seventh virtual conosle (/dev/vt/7), and users will use Alt + F7 to switch from consoles to Xserver, which normally picks up the first available virtual console. # svcs | grep login online 17:49:11 svc:/system/console-login:default online 17:49:11 svc:/system/console-login:vt2 online 17:49:11 svc:/system/console-login:vt3 online 17:49:11 svc:/system/console-login:vt4 online 17:49:11 svc:/system/console-login:vt5 online 17:49:11 svc:/system/console-login:vt6 console-login:default is for the system console, others for virtual consoles. Users can modify properties/disable/enable and remove/add virtual consoles using smf(5). Note that there's a limitation of smf to inherit some properties, especially property group. So in order to add another virtual console instance, currently users have to manually add ttymon property group and all the properties after adding an instance: # svccfg -s console-login add vt8 # svccfg -s console-login:vt8 addpg ttymon application # svccfg -s console-login:vt8 setprop ttymon/device=astring: "/dev/vt/8" # svccfg -s console-login:vt8 setprop ttymon/prompt=astring: "\"`uname -n` vt8 login:\"" # svccfg -s console-login:vt8 setprop ttymon/terminal_type=astring: "\"\"" # svccfg -s console-login:vt8 setprop ttymon/timeout=count: 0 # svccfg -s console-login:vt8 setprop ttymon/modules=astring: "ldterm,ttcompat" # svccfg -s console-login:vt8 setprop ttymon/nohangup= boolean: "true" # svccfg -s console-login:vt8 setprop ttymon/label=astring: "console" # svcadm enable console-login:vt8