dce@mips.COM (David Elliott) (09/17/88)
We have found that running some DEC VT100 terminals on our systems (any
Mips system running the System V.3-based os) has problems in vi.
Specifically, we find that if we edit a large file and page through it
rapidly by holding down 'j' or the down arrow, the terminal starts
displaying parity errors at the beginnings of lines. Similar things
happen when we page up using 'k' or the up arrow key.
I looked at the terminfo entry and the curses library source, and found
the following:
The terminfo entry has xon, which tells curses not to do padding,
since the terminal doesn't handle XON/XOFF very well. When I
removed xon, going up worked better because padding occurred.
I went on to add padding (3 ms) to the cr string (setting it to
cr=\r$<3>) and everything worked better.
My question is this: Do some VT100s not do XON/XOFF handshaking
properly, or is it more likely that we aren't doing XON/XOFF
correctly?
--
David Elliott dce@mips.com or {ames,prls,pyramid,decwrl}!mips!dcegwyn@smoke.ARPA (Doug Gwyn ) (09/18/88)
In article <3340@dunkshot.mips.COM> dce@mips.COM (David Elliott) writes: >My question is this: Do some VT100s not do XON/XOFF handshaking >properly, or is it more likely that we aren't doing XON/XOFF >correctly? VT100s to the best of my knowledge perform DC3/DC1 flow control correctly, but they have a very small input buffer which is easy to overrun if the host system is not very responsive. Most UNIX VT100 users who have flow control problems have failed to execute "stty ixon -ixany" in their .profile or other means of setting up terminal parameters when logging in. Applications are then expected to maintain this part of the terminal handler state when changing modes, the same way that the bit rate must be maintained. Older UNIX systems made this hard to do since switching out of fully-cooked mode would also disable flow control. Modern ones do have the capability of retaining flow control when switching modes. Some applications, notable some versions of EMACS, do not honor flow control and will disable it, thereby rendering terminals such as the VT100 unusable with those applications. (Use of padding or other timing-based kludges is NOT an acceptable substitute.) Complain loudly about such bugs to their vendors. P.S. If your VT100s have DEI VT640 RetroGraphics enhancements, you need to enable DC3/DC1 flow control in both the VT100 part AND the VT640 part.
guy@gorodish.Sun.COM (Guy Harris) (09/18/88)
> Most UNIX VT100 users who have flow control problems have failed > to execute "stty ixon -ixany" in their .profile or other means > of setting up terminal parameters when logging in. Note that when Doug said "-ixany", he meant it!. VT100s prefer the host to strictly obey the ^S/^Q conventions, and not turn output back on just because they received a character. ("ixon" is generally set by default on systems with an S3/S5-style "ioctl" interface, which is the one for which "ixon" and "-ixany" are the proper settings.) > Older UNIX systems made this hard to do since switching out of fully-cooked > mode would also disable flow control. Modern ones do have the capability of > retaining flow control when switching modes. Just about all versions of UNIX out there are "modern" in this sense, as long as you switch into "cbreak" mode, rather than "raw" mode, on systems that have the V7-style "ioctl" interface. Systems with a V6-style interface lost, but then those systems may not have had ^S/^Q flow control anyway. "raw" mode was generally intended for binary data transfers (e.g., UUCP), while "cbreak" mode was what was to be used for "full-screen" interactive applications (e.g., "vi"). The *ONLY* time "raw" mode should be used for "full-screen" interactive applications are those times when: 1) the system has only a V7-style "ioctl" interface; 2) the application needs an 8-bit path to the terminal (e.g., EMACS on terminals with a "meta" key that sets the 8th bit on characters); 3) there is no "pass8" mode (as there is in 4.3BSD). 4) the application also wants to see ^S and ^Q characters. If you only have the V7-style interface, you tend to get the equivalent of "stty ixon" by default. If the system only supports the V7 interface, there's no equivalent of "stty -ixany", so you may lose; if the system supports the BSD interface, the equivalent of "stty -ixany" is "stty decctlq". However, even on systems that support both the equivalent of "ixon" and "-ixany", there may be an additional source of problems. UNIX tends to protect critical regions in device drivers and the like by raising the interrupt priority; some measurements somebody once did indicated that the system on which the measurements were done (essentially a VAX-11/780 running 4.2BSD) spendt a fair bit of time with the interrupt priority raised to a level above the level at which the serial port hardware interrupted. If it spent enough time at that level, and if the serial port was run at a high-enough baud rate, it is conceivable that the driver might not see the interrupt indicating that the ^S came in, and thus might not see the ^S itself, in time to stop output before the VT100's buffer overran.
gwyn@smoke.ARPA (Doug Gwyn ) (09/18/88)
In article <68816@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes: >The *ONLY* time "raw" mode should be used for "full-screen" interactive >applications are those times when: Add another one: 5) keys must not generate signals. As I'm sure Guy knows, 7th Edition-based tty handler modes were just not sufficiently fine-grained and orthogonal. The USG tty handler was a considerable improvement in this regard, and any POSIX-conforming implementation will be. >If it spent enough time at that level, and if the serial port was run at a >high-enough baud rate, it is conceivable that the driver might not see the >interrupt indicating that the ^S came in, and thus might not see the ^S itself, >in time to stop output before the VT100's buffer overran. This problem can really occur only if the tty port output is done in large chunks, for example via DMA, and no provision has been made for incoming tty port input to be immediately processed and the DMA aborted when a DC3 is seen. I've seen a botch like this, by the way, but since the vendor fixed their hardware, firmware, and software to solve the problem I don't think I need to say who it was.
guy@gorodish.Sun.COM (Guy Harris) (09/19/88)
> >The *ONLY* time "raw" mode should be used for "full-screen" interactive > >applications are those times when: > Add another one: > 5) keys must not generate signals. And another one: 6) the application must require neither parity generation on output nor any other special output processing (such as tab expansion, conversion of '\n' to CR-LF, etc.). > >If it spent enough time at that level, and if the serial port was run at a > >high-enough baud rate, it is conceivable that the driver might not see the > >interrupt indicating that the ^S came in, and thus might not see the ^S > >itself, in time to stop output before the VT100's buffer overran. > This problem can really occur only if the tty port output is done > in large chunks, for example via DMA, and no provision has been made > for incoming tty port input to be immediately processed and the DMA > aborted when a DC3 is seen. I've seen a botch like this, by the way, > but since the vendor fixed their hardware, firmware, and software to > solve the problem I don't think I need to say who it was. Well, maybe. I no longer remember whether the VAX in question had DZs (with no DMA output) or DHs; offhand, it seems that if it had DZs the problem I cited wouldn't occur (since output is also interrupt-driven, and if the input interrupt signalling the arrival of the ^S were held off, the output interrupt telling the host to send the next character would also be held off), but if it had DHs the problem could occur (since DHs did have DMA output, and since the hardware didn't recognize ^S and stop immediately - that was up to the software).
marc@okeeffe.Berkeley.EDU (Marc Teitelbaum) (09/19/88)
In article <8527@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <68816@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes: >>The *ONLY* time "raw" mode should be used for "full-screen" interactive >>applications are those times when: > >Add another one: > 5) keys must not generate signals. > No - keyboard signals are not a reason to avoid CBREAK. Traditionally this is handled in BSD by setting CBREAK and disabling all special characters. I concede this would have been true in V7, but special characters have been settable since 3BSD. There have always been two schools of thought here. The first one thinks a raw i/o path should be just that - completely raw, and the second school (the practical school) realizes that many functions, such as flow control and interrupts, just can't be ignored and usually must be done locally. And it's unfortunate that games must be played with flow control and interrupts over network connections, but they're necessary. I'm not sure the 8-bit argument for using RAW is valid either. Setting both LITOUT and PASS8 in addition to CBREAK and disabling special characters might be sufficient for applications which want 8-bit, a fairly raw i/o path, and which still have to process flow control locally. This still won't cut it for people who use ^S in emacs - c'est la vie. And programs which really want to transfer data transparently should still use RAW - but these programs aren't typically connected to terminals (or people). Also, be aware that using PASS8 makes quoting input characters impossible (either literal next or '\'). In fact, trying to quote a character will just succeed in setting its 8-th bit. This is a bug without a one-line fix - luckily the next release of BSD fixes this. >As I'm sure Guy knows, 7th Edition-based tty handler modes were just >not sufficiently fine-grained and orthogonal. The USG tty handler >was a considerable improvement in this regard, and any POSIX-conforming >implementation will be. No argument here, however i still can't believe the ISIG and ICANON flags are in the *l*flag element. And considering these flags are bit masks which can't be type-checked at compile time, this is a real blunder. I can see lots of new termio(s) programmers thinking ISIG and ICANON belong in the iflag... Marc ------------------------------- Marc Teitelbaum +1-415-643-6448 457 Evans Hall Computer Systems Research Group, CSRG / DEC University of California Berkeley, CA 94720
dtynan@sultra.UUCP (Dermot Tynan) (09/20/88)
In article <3340@dunkshot.mips.COM>, dce@mips.COM (David Elliott) writes: > > My question is this: Do some VT100s not do XON/XOFF handshaking > properly, or is it more likely that we aren't doing XON/XOFF > correctly? > > David Elliott dce@mips.com or {ames,prls,pyramid,decwrl}!mips!dce I have a similar problem. I wrote the control software for a client, which includes an RS-232 port for sending commands, and receiving status. I wrote an advanced (in *my* opinion, anyway) serial driver, including X-ON/X-OFF pacing. I used a beat-up Hazeltine to debug the code, and the old dog ran to 19.2Kb (without pacing!) no problems. My problems started when I put a VT100 on there. Every once in a while, the whole thing hangs. It looks as though the VT100 sent an X-OFF, without an X-ON. If I enter and exit the SETUP menu, on the terminal, the problem goes away. Also, it stops when I run the terminal at 4.8Kb or less. At 19.2, the terminal blasts pacing controls down the wire, like they were going out of business. It's a real pain, because the system starts to detect major problems when it sees the terminal as being offline all of a sudden. I can't find anything in my code which could cause this (of course, that's not to say that there isn't anything there :-), and at this stage, I'm considering specifying the use of a terminal other than the VT100. Can you beleive that antique Hazeltine can handle the speed, and the VT100 can barely handle 9600 baud without pacing the interface? Anyway, I too would like to hear of other peoples problems in this regard. - Der -- Reply: dtynan@sultra.UUCP (Dermot Tynan @ Tynan Computers) {mips,pyramid}!sultra!dtynan Cast a cold eye on life, on death. Horseman, pass by... [WBY]
guy@gorodish.Sun.COM (Guy Harris) (09/20/88)
> >>The *ONLY* time "raw" mode should be used for "full-screen" interactive > >>applications are those times when: > > > >Add another one: > > 5) keys must not generate signals. > > > > No - keyboard signals are not a reason to avoid CBREAK. We all agree, but they *are* a reason to avoid "raw" mode, since it doesn't support keyboard signals. The list given was a list of conditions, all of which should be true before you use "raw" mode. Even if they are true, CBREAK mode may still be appropriate; if one of them is not true, RAW mode is inappropriate. > Traditionally this is handled in BSD by setting CBREAK and disabling all > special characters. I concede this would have been true in V7, but special > characters have been settable since 3BSD. Careful what you concede; V7 let you set the special characters. > I'm not sure the 8-bit argument for using RAW is valid either. Given that the argument was "if you DON'T want an 8-bit data path, DON'T use raw mode", it is valid. The converse, of course, doesn't follow; if you want an 8-bit data path, you need not necessarily use raw mode. > Also, be aware that using PASS8 makes quoting input characters > impossible (either literal next or '\'). In fact, trying to quote > a character will just succeed in setting its 8-th bit. This is a > bug without a one-line fix - luckily the next release of BSD fixes this. SunOS 4.0 also handles this correctly. > No argument here, however i still can't believe the ISIG and ICANON > flags are in the *l*flag element. And considering these flags are > bit masks which can't be type-checked at compile time, this is a real > blunder. I can see lots of new termio(s) programmers thinking ISIG > and ICANON belong in the iflag... I think I know of one program - perhaps even one distributed with S3 - where it *was* stting either the ISIG or ICANON bit in "c_iflag". The names are somewhat bogus....
gwyn@smoke.ARPA (Doug Gwyn ) (09/21/88)
In article <2408@sultra.UUCP> dtynan@sultra.UUCP (Dermot Tynan) writes: >Can you beleive that antique Hazeltine can handle the >speed, and the VT100 can barely handle 9600 baud without pacing the interface? But does your Hazeltine do smooth scrolling? That's a very nice VT100 feature, that obviously requires flow control.