I have an AccelePort 8r PCI (PLX) and a DEC VT420 as well as a Wyse WY-160ES terminal connected to it (Debian 3.0 “Woody” on a x86 PC). My problem is that the ^S flow control character is being delivered to the program running in the foreground instead of being intercepted by the terminal line discipline. Accordingly the host keeps sending data to the terminal which results in garbage on the screen and also the application executing whatever it is supposed to do on receipt of a ^S.
I tried both driver versions (epca v1.56 and dgap v1.1) which make no difference. Of course Xon/Xoff flow control is enabled:
Interesting. Typing ^S and ^Q while “ls -l /dev” is running (dont have /etc/termcap) works, i.e. they stop and restart the flow as one would expect. Does this tell you something?
Ctrl-S and Ctrl-Q are the characters which correspond to Xon and Xoff, i.e. software flow control. It sounds like Xon/Xoff flow control is working properly, since you can do it manually.
> Ctrl-S and Ctrl-Q are the characters which correspond
> to Xon and Xoff, i.e. software flow control. It
> sounds like Xon/Xoff flow control is working
> properly, since you can do it manually.
Mmmh, I’d rather say it’s working almost properly. For pure printable characters (e.g. directory listings, cat’ing text files) it seems to work. But with curses-based apps it does not. Maybe it has something to do with their heavy usage of escape sequences?
Just to be clear, I’m quite sure that it’s definitely the ^S not being recognized by the terminal line discipline and not some other weird misconfiguration on my side (info browser starting “I-Search” which is bound to ^S, vi displaying “^S isn’t a vi command” etc.). Hardware handshaking works perfectly even at 38400 bps, BTW.
When Xon/Xoff is configured with the epca/dgap drivers, the software flow control is done in the FEP (firmware).
Even if the FEP missed it, (very unlikely), the Linux line discipline would have caught it.
This suggests that your application is turning off xon/xoff, or is changing the characters that trigger xon/xoff.
When your application is running, and ctrl-s is sent to stop output, perform a ditty -a ttyx##, to see if xon and xoff are activated, along with the start/stop characters (i.e.: start = ^Q and stop = ^S).
> When Xon/Xoff is configured with the epca/dgap
> drivers, the software flow control is done in the FEP
> (firmware).
> Even if the FEP missed it, (very unlikely), the Linux
> line discipline would have caught it.
Never mind. It has nothing to do with the AccelePort. After some more extensive testing and experimenting I finally got the unbelievably genious idea to test it with the onboard serial port of the computer. And guess what - the symptoms are exactly the same.
> This suggests that your application is turning off
> xon/xoff, or is changing the characters that trigger
> xon/xoff.
>
> When your application is running, and ctrl-s is sent
> to stop output, perform a ditty -a ttyx##, to see if
> xon and xoff are activated, along with the start/stop
> characters (i.e.: start = ^Q and stop = ^S).
Er, yes. All the curses-based programs disable flow control (-ixon)! So I guess it’s the curses library fault. I will investigate this issue further.