1.\" $NetBSD: tty.4,v 1.10 2000/03/23 19:48:29 mycroft Exp $ 2.\" 3.\" Copyright (c) 1991, 1992, 1993 4.\" The Regents of the University of California. All rights reserved. 5.\" 6.\" Redistribution and use in source and binary forms, with or without 7.\" modification, are permitted provided that the following conditions 8.\" are met: 9.\" 1. Redistributions of source code must retain the above copyright 10.\" notice, this list of conditions and the following disclaimer. 11.\" 2. Redistributions in binary form must reproduce the above copyright 12.\" notice, this list of conditions and the following disclaimer in the 13.\" documentation and/or other materials provided with the distribution. 14.\" 3. All advertising materials mentioning features or use of this software 15.\" must display the following acknowledgement: 16.\" This product includes software developed by the University of 17.\" California, Berkeley and its contributors. 18.\" 4. Neither the name of the University nor the names of its contributors 19.\" may be used to endorse or promote products derived from this software 20.\" without specific prior written permission. 21.\" 22.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND 23.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 24.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 25.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE 26.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 27.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 28.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 29.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 30.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 31.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 32.\" SUCH DAMAGE. 33.\" 34.\" @(#)tty.4 8.3 (Berkeley) 4/19/94 35.\" 36.Dd August 14, 1992 37.Dt TTY 4 38.Os 39.Sh NAME 40.Nm tty 41.Nd general terminal interface 42.Sh SYNOPSIS 43.Fd #include <sys/ioctl.h> 44.Sh DESCRIPTION 45This section describes the interface to the terminal drivers 46in the system. 47.Ss Terminal Special Files 48Each hardware terminal port on the system usually has two terminal special 49device files associated with it in the directory ``/dev/'' (for 50example, ``/dev/tty03'' and ``/dev/dty03''). 51.Pp 52The ``/dev/ttyXX'' special file is used for dialin modems and terminals. 53When a user logs into 54the system on one of these hardware terminal ports, the system has already 55opened the associated device and prepared the line for normal interactive 56use (see 57.Xr getty 8 .) 58.Pp 59The ``/dev/dtyXX'' special file is a SunOS-compatible dialout device. Unlike 60the dialin device, opening the dialout device never blocks. If the 61corresponding dialin device is already opened (not blocked in the open waiting 62for carrier), then the dialout open will fail immediately; otherwise it will 63succeed immediately. While the dialout device is open, the dialin device may 64not be opened. If the dialin open is blocking, it will wait until the dialout 65device is closed (and carrier is detected); otherwise it will fail immediately. 66.Pp 67There is also a special case of a terminal file that connects not to 68a hardware terminal port, but to another program on the other side. 69These special terminal devices are called 70.Em ptys 71and provide the mechanism necessary to give users the same interface to the 72system when logging in over a network (using 73.Xr rlogin 1 , 74or 75.Xr telnet 1 76for example.) Even in these cases the details of how the terminal 77file was opened and set up is already handled by special software 78in the system. 79Thus, users do not normally need to worry about the details of 80how these lines are opened or used. Also, these lines are often used 81for dialing out of a system (through an out-calling modem), but again 82the system provides programs that hide the details of accessing 83these terminal special files (see 84.Xr tip 1 ) . 85.Pp 86When an interactive user logs in, the system prepares the line to 87behave in a certain way (called a 88.Em "line discipline" ) , 89the particular details of which is described in 90.Xr stty 1 91at the command level, and in 92.Xr termios 4 93at the programming level. A user may be concerned with changing 94settings associated with his particular login terminal and should refer 95to the preceding man pages for the common cases. The remainder of 96this man page is concerned 97with describing details of using and controlling terminal devices 98at a low level, such as that possibly required by a program wishing 99to provide features similar to those provided by the system. 100.Ss Line disciplines 101A terminal file is used like any other file in the system in that 102it can be opened, read, and written to using standard system 103calls. For each existing terminal file, there is a software processing module 104called a 105.Em "line discipline" 106is associated with it. The 107.Em "line discipline" 108essentially glues the low level device driver code with the high 109level generic interface routines (such as 110.Xr read 2 111and 112.Xr write 2 ), 113and is responsible for implementing the semantics associated 114with the device. When a terminal file is first opened by a program, 115the default 116.Em "line discipline" 117called the 118.Dv termios 119line discipline is associated with the file. This is the primary 120line discipline that is used in most cases and provides the semantics 121that users normally associate with a terminal. When the 122.Dv termios 123line discipline is in effect, the terminal file behaves and is 124operated according to the rules described in 125.Xr termios 4 . 126Please refer to that man page for a full description of the terminal 127semantics. 128The operations described here 129generally represent features common 130across all 131.Em "line disciplines" , 132however some of these calls may not 133make sense in conjunction with a line discipline other than 134.Dv termios , 135and some may not be supported by the underlying 136hardware (or lack thereof, as in the case of ptys). 137.Ss Terminal File Operations 138All of the following operations are invoked using the 139.Xr ioctl 2 140system call. Refer to that man page for a description of 141the 142.Em request 143and 144.Em argp 145parameters. 146In addition to the ioctl 147.Em requests 148defined here, the specific line discipline 149in effect will define other 150.Em requests 151specific to it (actually 152.Xr termios 4 153defines them as function calls, not ioctl 154.Em requests . ) 155The following section lists the available ioctl requests. The 156name of the request, a description of its purpose, and the typed 157.Em argp 158parameter (if any) 159are listed. For example, the first entry says 160.Pp 161.D1 Em "TIOCSETD int *ldisc" 162.Pp 163and would be called on the terminal associated with 164file descriptor zero by the following code fragment: 165.Bd -literal 166 int ldisc; 167 168 ldisc = TTYDISC; 169 ioctl(0, TIOCSETD, &ldisc); 170.Ed 171.Ss Terminal File Request Descriptions 172.Bl -tag -width TIOCGWINSZ 173.It Dv TIOCSETD Fa int *ldisc 174Change to the new line discipline pointed to by 175.Fa ldisc . 176The available line disciplines are listed in 177.Pa Aq sys/ttycom.h 178and currently are: 179.Pp 180.Bl -tag -width TIOCGWINSZ -compact 181.It TTYDISC 182Termios interactive line discipline. 183.It TABLDISC 184Tablet line discipline. 185.It SLIPDISC 186Serial IP line discipline. 187.It PPPDISC 188Point to Point Protocol line discipline. 189.It STRIPDISC 190Starmode Radio IP line discipline. 191.El 192.Pp 193.It Dv TIOCGETD Fa int *ldisc 194Return the current line discipline in the integer pointed to by 195.Fa ldisc . 196.It Dv TIOCSBRK Fa void 197Set the terminal hardware into BREAK condition. 198.It Dv TIOCCBRK Fa void 199Clear the terminal hardware BREAK condition. 200.It Dv TIOCSDTR Fa void 201Assert data terminal ready (DTR). 202.It Dv TIOCCDTR Fa void 203Clear data terminal ready (DTR). 204.It Dv TIOCGPGRP Fa int *tpgrp 205Return the current process group the terminal is associated 206with in the integer pointed to by 207.Fa tpgrp . 208This is the underlying call that implements the 209.Xr termios 4 210.Fn tcgetattr 211call. 212.It Dv TIOCSPGRP Fa int *tpgrp 213Associate the terminal with the process group (as an integer) pointed to by 214.Fa tpgrp . 215This is the underlying call that implements the 216.Xr termios 4 217.Fn tcsetattr 218call. 219.It Dv TIOCGETA Fa struct termios *term 220Place the current value of the termios state associated with the 221device in the termios structure pointed to by 222.Fa term . 223This is the underlying call that implements the 224.Xr termios 4 225.Fn tcgetattr 226call. 227.It Dv TIOCSETA Fa struct termios *term 228Set the termios state associated with the device immediately. 229This is the underlying call that implements the 230.Xr termios 4 231.Fn tcsetattr 232call with the 233.Dv TCSANOW 234option. 235.It Dv TIOCSETAW Fa struct termios *term 236First wait for any output to complete, then set the termios state 237associated with the device. 238This is the underlying call that implements the 239.Xr termios 4 240.Fn tcsetattr 241call with the 242.Dv TCSADRAIN 243option. 244.It Dv TIOCSETAF Fa struct termios *term 245First wait for any output to complete, clear any pending input, 246then set the termios state associated with the device. 247This is the underlying call that implements the 248.Xr termios 4 249.Fn tcsetattr 250call with the 251.Dv TCSAFLUSH 252option. 253.It Dv TIOCOUTQ Fa int *num 254Place the current number of characters in the output queue in the 255integer pointed to by 256.Fa num . 257.It Dv TIOCSTI Fa char *cp 258Simulate typed input. Pretend as if the terminal received the 259character pointed to by 260.Fa cp . 261.It Dv TIOCNOTTY Fa void 262This call is obsolete but left for compatibility. In the past, when 263a process that didn't have a controlling terminal (see 264.Em The Controlling Terminal 265in 266.Xr termios 4 ) 267first opened a terminal device, it acquired that terminal as its 268controlling terminal. For some programs this was a hazard as they 269didn't want a controlling terminal in the first place, and this 270provided a mechanism to disassociate the controlling terminal from 271the calling process. It 272.Em must 273be called by opening the file 274.Pa /dev/tty 275and calling 276.Dv TIOCNOTTY 277on that file descriptor. 278.Pp 279The current system does not allocate a controlling terminal to 280a process on an 281.Fn open 282call: there is a specific ioctl called 283.Dv TIOCSCTTY 284to make a terminal the controlling 285terminal. 286In addition, a program can 287.Fn fork 288and call the 289.Fn setsid 290system call which will place the process into its own session - which 291has the effect of disassociating it from the controlling terminal. This 292is the new and preferred method for programs to lose their controlling 293terminal. 294.It Dv TIOCSTOP Fa void 295Stop output on the terminal (like typing ^S at the keyboard). 296.It Dv TIOCSTART Fa void 297Start output on the terminal (like typing ^Q at the keyboard). 298.It Dv TIOCSCTTY Fa void 299Make the terminal the controlling terminal for the process (the process 300must not currently have a controlling terminal). 301.It Dv TIOCDRAIN Fa void 302Wait until all output is drained. 303.It Dv TIOCEXCL Fa void 304Set exclusive use on the terminal. No further opens are permitted 305except by root. Of course, this means that programs that are run by 306root (or setuid) will not obey the exclusive setting - which limits 307the usefulness of this feature. 308.It Dv TIOCNXCL Fa void 309Clear exclusive use of the terminal. Further opens are permitted. 310.It Dv TIOCFLUSH Fa int *what 311If the value of the int pointed to by 312.Fa what 313contains the 314.Dv FREAD 315bit as defined in 316.Pa Aq sys/fcntl.h , 317then all characters in the input queue are cleared. If it contains 318the 319.Dv FWRITE 320bit, then all characters in the output queue are cleared. If the 321value of the integer is zero, then it behaves as if both the 322.Dv FREAD 323and 324.Dv FWRITE 325bits were set (i.e. clears both queues). 326.It Dv TIOCGWINSZ Fa struct winsize *ws 327Put the window size information associated with the terminal in the 328.Va winsize 329structure pointed to by 330.Fa ws . 331The window size structure contains the number of rows and columns (and pixels 332if appropriate) of the devices attached to the terminal. It is set by user software 333and is the means by which most full\&-screen oriented programs determine the 334screen size. The 335.Va winsize 336structure is defined in 337.Pa Aq sys/ioctl.h . 338.It Dv TIOCSWINSZ Fa struct winsize *ws 339Set the window size associated with the terminal to be the value in 340the 341.Va winsize 342structure pointed to by 343.Fa ws 344(see above). 345.It Dv TIOCCONS Fa int *on 346If 347.Fa on 348points to a non-zero integer, redirect kernel console output (kernel printf's) 349to this terminal. 350If 351.Fa on 352points to a zero integer, redirect kernel console output back to the normal 353console. This is usually used on workstations to redirect kernel messages 354to a particular window. 355.It Dv TIOCMSET Fa int *state 356The integer pointed to by 357.Fa state 358contains bits that correspond to modem state. Following is a list 359of defined variables and the modem state they represent: 360.Pp 361.Bl -tag -width TIOCMXCTS -compact 362.It TIOCM_LE 363Line Enable. 364.It TIOCM_DTR 365Data Terminal Ready. 366.It TIOCM_RTS 367Request To Send. 368.It TIOCM_ST 369Secondary Transmit. 370.It TIOCM_SR 371Secondary Receive. 372.It TIOCM_CTS 373Clear To Send. 374.It TIOCM_CAR 375Carrier Detect. 376.It TIOCM_CD 377Carier Detect (synonym). 378.It TIOCM_RNG 379Ring Indication. 380.It TIOCM_RI 381Ring Indication (synonym). 382.It TIOCM_DSR 383Data Set Ready. 384.El 385.Pp 386This call sets the terminal modem state to that represented by 387.Fa state . 388Not all terminals may support this. 389.It Dv TIOCMGET Fa int *state 390Return the current state of the terminal modem lines as represented 391above in the integer pointed to by 392.Fa state . 393.It Dv TIOCMBIS Fa int *state 394The bits in the integer pointed to by 395.Fa state 396represent modem state as described above, however the state is OR-ed 397in with the current state. 398.It Dv TIOCMBIC Fa int *state 399The bits in the integer pointed to by 400.Fa state 401represent modem state as described above, however each bit which is on 402in 403.Fa state 404is cleared in the terminal. 405.It Dv TIOCSFLAGS Fa int *state 406The bits in the integer pointed to by 407.Fa state 408contain bits that correspond to serial port state. Following is a list 409of defined variables and the serial port state they represent: 410.Pp 411.Bl -tag -width TIOCFLAG_SOFTCAR -compact 412.It TIOCFLAG_SOFTCAR 413Ignore hardware carrier. 414.It TIOCFLAG_CLOCAL 415Set clocal on open. 416.It TIOCFLAG_CRTSCTS 417Set crtscts on open. 418.It TIOCFLAG_MDMBUF 419Set mdmbuf on open. 420.El 421.Pp 422This call sets the serial port state to that represented by 423.Fa state . 424Not all serial ports may support this. 425.It Dv TIOCGFLAGS Fa int *state 426Return the current state of the serial port as represented 427above in the integer pointed to by 428.Fa state . 429.El 430.Sh HISTORY 431Separate dialout device files were implemented in SunOS 4. They were cloned 432by Charles M. Hannum for 433.Nx 1.4 . 434.Sh SEE ALSO 435.Xr getty 8 , 436.Xr ioctl 2 , 437.Xr pty 4 , 438.Xr stty 1 , 439.Xr termios 4 440