1termiox(7I) Ioctl Requests termiox(7I)
2
6 termiox - extended general terminal interface
7
9 The extended general terminal interface supplements the termio(7I) gen‐
10 eral terminal interface by adding support for asynchronous hardware
11 flow control, isochronous flow control and clock modes, and local
12 implementations of additional asynchronous features. Some systems may
13 not support all of these capabilities because of either hardware or
14 software limitations. Other systems may not permit certain functions
15 to be disabled. In these cases the appropriate bits will be ignored.
16 See <sys/termiox.h> for your system to find out which capabilities are
17 supported.
18 Hardware Flow Control Modes
20 Hardware flow control supplements the termio(7I) IXON, IXOFF, and IXANY
21 character flow control. Character flow control occurs when one device
22 controls the data transfer of another device by the insertion of con‐
23 trol characters in the data stream between devices. Hardware flow con‐
24 trol occurs when one device controls the data transfer of another
25 device using electrical control signals on wires (circuits) of the
26 asynchronous interface. Isochronous hardware flow control occurs when
27 one device controls the data transfer of another device by asserting
28 or removing the transmit clock signals of that device. Character flow
29 control and hardware flow control may be simultaneously set.
30 In asynchronous, full duplex applications, the use of the Electronic
33 Industries Association's EIA-232-D Request To Send (RTS) and Clear To
34 Send (CTS) circuits is the preferred method of hardware flow control.
35 An interface to other hardware flow control methods is included to pro‐
36 vide a standard interface to these existing methods.
37 The EIA-232-D standard specified only unidirectional hardware flow con‐
40 trol - the Data Circuit-terminating Equipment or Data Communications
41 Equipment (DCE) indicates to the Data Terminal Equipment (DTE) to stop
42 transmitting data. The termiox interface allows both unidirectional
43 and bidirectional hardware flow control; when bidirectional flow con‐
44 trol is enabled, either the DCE or DTE can indicate to each other to
45 stop transmitting data across the interface. Note: It is assumed that
46 the asynchronous port is configured as a DTE. If the connected device
47 is also a DTE and not a DCE, then DTE to DTE (for example, terminal or
48 printer connected to computer) hardware flow control is possible by
49 using a null modem to interconnect the appropriate data and control
50 circuits.
51 Clock Modes
53 Isochronous communication is a variation of asynchronous communication
54 whereby two communicating devices may provide transmit and/or receive
55 clock signals to one another. Incoming clock signals can be taken from
56 the baud rate generator on the local isochronous port controller, from
57 CCITT V.24 circuit 114, Transmitter Signal Element Timing - DCE source
58 (EIA-232-D pin 15), or from CCITT V.24 circuit 115, Receiver Signal
59 Element Timing - DCE source (EIA-232-D pin 17). Outgoing clock signals
60 can be sent on CCITT V.24 circuit 113, Transmitter Signal Element Tim‐
61 ing - DTE source (EIA-232-D pin 24), on CCITT V.24 circuit 128,
62 Receiver Signal Element Timing - DTE source (no EIA-232-D pin), or not
63 sent at all.
64 In terms of clock modes, traditional asynchronous communication is
67 implemented simply by using the local baud rate generator as the incom‐
68 ing transmit and receive clock source and not outputting any clock sig‐
69 nals.
70 Terminal Parameters
72 The parameters that control the behavior of devices providing the
73 termiox interface are specified by the termiox structure defined in the
74 <sys/termiox.h> header. Several ioctl(2) system calls that fetch or
75 change these parameters use this structure:
76 #define NFF 5
78 struct termiox {
79 unsigned short x_hflag; /* hardware flow control modes */
80 unsigned short x_cflag; /* clock modes */
81 unsigned short x_rflag[NFF]; /* reserved modes */
82 unsigned short x_sflag; /* spare local modes */
83 };
84 The x_hflag field describes hardware flow control modes:
88 RTSXOFF 0000001 Enable RTS hardware flow control
93 on input.
94 CTSXON 0000002 Enable CTS hardware flow control
95 on output.
96 DTRXOFF 0000004 Enable DTR hardware flow control
97 on input.
98 CDXON 0000010 Enable CD hardware flow control
99 on output.
100 ISXOFF 0000020 Enable isochronous hardware flow
101 control on input
102 The EIA-232-D DTR and CD circuits are used to establish a connection
106 between two systems. The RTS circuit is also used to establish a con‐
107 nection with a modem. Thus, both DTR and RTS are activated when an
108 asynchronous port is opened. If DTR is used for hardware flow control,
109 then RTS must be used for connectivity. If CD is used for hardware flow
110 control, then CTS must be used for connectivity. Thus, RTS and DTR (or
111 CTS and CD) cannot both be used for hardware flow control at the same
112 time. Other mutual exclusions may apply, such as the simultaneous set‐
113 ting of the termio(7I) HUPCL and the termiox DTRXOFF bits, which use
114 the DTE ready line for different functions.
115 Variations of different hardware flow control methods may be selected
118 by setting the the appropriate bits. For example, bidirectional RTS/CTS
119 flow control is selected by setting both the RTSXOFF and CTSXON bits
120 and bidirectional DTR/CTS flow control is selected by setting both the
121 DTRXOFF and CTSXON. Modem control or unidirectional CTS hardware flow
122 control is selected by setting only the CTSXON bit.
123 As previously mentioned, it is assumed that the local asynchronous port
126 (for example, computer) is configured as a DTE. If the connected
127 device (for example, printer) is also a DTE, it is assumed that the
128 device is connected to the computer's asynchronous port using a null
129 modem that swaps control circuits (typically RTS and CTS). The con‐
130 nected DTE drives RTS and the null modem swaps RTS and CTS so that the
131 remote RTS is received as CTS by the local DTE. In the case that
132 CTSXON is set for hardware flow control, printer's lowering of its RTS
133 would cause CTS seen by the computer to be lowered. Output to the
134 printer is suspended until the printer's raising of its RTS, which
135 would cause CTS seen by the computer to be raised.
136 If RTSXOFF is set, the Request To Send (RTS) circuit (line) will be
139 raised, and if the asynchronous port needs to have its input stopped,
140 it will lower the Request To Send (RTS) line. If the RTS line is low‐
141 ered, it is assumed that the connected device will stop its output
142 until RTS is raised.
143 If CTSXON is set, output will occur only if the Clear To Send (CTS)
146 circuit (line) is raised by the connected device. If the CTS line is
147 lowered by the connected device, output is suspended until CTS is
148 raised.
149 If DTRXOFF is set, the DTE Ready (DTR) circuit (line) will be raised,
152 and if the asynchronous port needs to have its input stopped, it will
153 lower the DTE Ready (DTR) line. If the DTR line is lowered, it is
154 assumed that the connected device will stop its output until DTR is
155 raised.
156 If CDXON is set, output will occur only if the Received Line Signal
159 Detector (CD) circuit (line) is raised by the connected device. If the
160 CD line is lowered by the connected device, output is suspended until
161 CD is raised.
162 If ISXOFF is set, and if the isochronous port needs to have its input
165 stopped, it will stop the outgoing clock signal. It is assumed that the
166 connected device is using this clock signal to create its output. Tran‐
167 sit and receive clock sources are programmed using the x_cflag fields.
168 If the port is not programmed for external clock generation, ISXOFF is
169 ignored. Output isochronous flow control is supported by appropriate
170 clock source programming using the x_cflag field and enabled at the
171 remote connected device.
172 The x_cflag field specifies the system treatment of clock modes.
175 XMTCLK 0000007 Transmit clock source:
180 XCIBRG 0000000 Get transmit clock from inter‐
181 nal baud rate generator.
182 XCTSET 0000001 Get transmit clock from trans‐
183 mitter signal element timing
184 (DCE source) lead, CCITT V.24
185 circuit 114, EIA-232-D pin 15.
186 XCRSET 0000002 Get transmit clock from
187 receiver signal element timing
188 (DCE source) lead, CCITT V.24
189 circuit 115, EIA-232-D pin 17.
190 RCVCLK 0000070 Receive clock source:
191 RCIBRG 0000000 Get receive clock from internal
192 baud rate generator.
193 RCTSET 0000010 Get receive clock from trans‐
194 mitter signal element timing
195 (DCE source) lead, CCITT V.24
196 circuit 114, EIA-232-D pin 15.
197 RCRSET 0000020 Get receive clock from receiver
200 signal element timing (DCE
201 source) lead, CCITT V.24 cir‐
202 cuit 115, EIA-232-D pin 17.
203 TSETCLK 0000700 Transmitter signal element tim‐
204 ing (DTE source) lead, CCITT
205 V.24 circuit 113, EIA-232-D pin
206 24, clock source:
207 TSETCOFF 0000000 TSET clock not provided.
208 TSETCRBRG 0000100 Output receive baud rate gener‐
209 ator on circuit 113.
210 TSETCTBRG 0000200 Output transmit baud rate gen‐
211 erator on circuit 113
212 TSETCTSET 0000300 Output transmitter signal ele‐
213 ment timing (DCE source) on
214 circuit 113.
215 TSETCRSET 0000400 Output receiver signal element
216 timing (DCE source) on circuit
217 113.
218 RSETCLK 0007000 Receiver signal element timing
219 (DTE source) lead, CCITT V.24
220 circuit 128, no EIA-232-D pin,
221 clock source:
222 RSETCOFF 0000000 RSET clock not provided.
223 RSETCRBRG 0001000 Output receive baud rate gener‐
224 ator on circuit 128.
225 RSETCTBRG 0002000 Output transmit baud rate gen‐
226 erator on circuit 128.
227 RSETCTSET 0003000 Output transmitter signal ele‐
228 ment timing (DCE source) on
229 circuit 128.
230 RSETCRSET 0004000 Output receiver signal element
231 timing (DCE) on circuit 128.
232 If the XMTCLK field has a value of XCIBRG the transmit clock is taken
236 from the hardware internal baud rate generator, as in normal asynchro‐
237 nous transmission. If XMTCLK = XCTSET the transmit clock is taken from
238 the Transmitter Signal Element Timing (DCE source) circuit. If XMTCLK =
239 XCRSET the transmit clock is taken from the Receiver Signal Element
240 Timing (DCE source) circuit.
241 If the RCVCLK field has a value of RCIBRG the receive clock is taken
244 from the hardware Internal Baud Rate Generator, as in normal asynchro‐
245 nous transmission. If RCVCLK = RCTSET the receive clock is taken from
246 the Transmitter Signal Element Timing (DCE source) circuit. If RCVCLK =
247 RCRSET the receive clock is taken from the Receiver Signal Element Tim‐
248 ing (DCE source) circuit.
249 If the TSETCLK field has a value of TSETCOFF the Transmitter Signal
252 Element Timing (DTE source) circuit is not driven. If TSETCLK = TSETCR‐
253 BRG the Transmitter Signal Element Timing (DTE source) circuit is
254 driven by the Receive Baud Rate Generator. If TSETCLK = TSETCTBRG the
255 Transmitter Signal Element Timing (DTE source) circuit is driven by the
256 Transmit Baud Rate Generator. If TSETCLK = TSETCTSET the Transmitter
257 Signal Element Timing (DTE source) circuit is driven by the Transmitter
258 Signal Element Timing (DCE source). If TSETCLK = TSETCRBRG the Trans‐
259 mitter Signal Element Timing (DTE source) circuit is driven by the
260 Receiver Signal Element Timing (DCE source).
261 If the RSETCLK field has a value of RSETCOFF the Receiver Signal Ele‐
264 ment Timing (DTE source) circuit is not driven. If RSETCLK = RSETCRBRG
265 the Receiver Signal Element Timing (DTE source) circuit is driven by
266 the Receive Baud Rate Generator. If RSETCLK = RSETCTBRG the Receiver
267 Signal Element Timing (DTE source) circuit is driven by the Transmit
268 Baud Rate Generator. If RSETCLK = RSETCTSET the Receiver Signal Element
269 Timing (DTE source) circuit is driven by the Transmitter Signal Element
270 Timing (DCE source). If RSETCLK = RSETCRBRG the Receiver Signal Element
271 Timing (DTE source) circuit is driven by the Receiver Signal Element
272 Timing (DCE source).
273 The x_rflag is reserved for future interface definitions and should not
276 be used by any implementations. The x_sflag may be used by local imple‐
277 mentations wishing to customize their terminal interface using the
278 termiox ioctl system calls.
279
281 The ioctl(2) system calls have the form:
282 ioctl (fildes, command, arg) struct termiox * arg;
284 The commands using this form are:
288 TCGETX The argument is a pointer to a termiox structure. The cur‐
290 rent terminal parameters are fetched and stored into that
291 structure.
292 TCSETX The argument is a pointer to a termiox structure. The cur‐
295 rent terminal parameters are set from the values stored in
296 that structure. The change is immediate.
297 TCSETXW The argument is a pointer to a termiox structure. The cur‐
300 rent terminal parameters are set from the values stored in
301 that structure. The change occurs after all characters
302 queued for output have been transmitted. This form should be
303 used when changing parameters that will affect output.
304 TCSETXF The argument is a pointer to a termiox structure. The cur‐
307 rent terminal parameters are set from the values stored in
308 that structure. The change occurs after all characters
309 queued for output have been transmitted; all characters
310 queued for input are discarded and then the change occurs.
311
314 /dev/*
315
317 stty(1), ioctl(2), termio(7I)
318
320 The termiox(7I) system call is provided for compatibility with previ‐
321 ous releases and its use is discouraged. Instead, the termio(7I)
322 system call is recommended. See termio(7I) for usage information.
323SunOS 5.11 3 Jul 1990 termiox(7I)