dave@lsuc.UUCP (David Sherman) (10/01/86)
Does anyone have experience with setting up terminal I/O at
different speeds under UNIX? We're running v7 ("Edition VII")
on a Perkin-Elmer 3220. The machine can output genuine 19200,
but loses characters when processing input on a tty line at
faster than 1200. This means that function keys on a VT-100
compatible (which transmit a multi-char sequence beginning
with ESC) sometimes aren't properly received. Since no-one
actually types faster than 1200 baud, I'd like to set up our
local terminals with 1200 in and 19200 out.
Obviously I'd have to hack stty(1) and getty to grok split speeds.
Are there any other gotchas I should be aware of? Do any of the
commonly-available applications programs which do gtty/stty(2)
or ioctl make assumptions about input and output being at the
same speed?
David Sherman
Computer Education Facility
The Law Society of Upper Canada
Osgoode Hall
Toronto, Canada M5H 2N6
dave@lsuc.UUCP
(416) 947-3466
--
{ ihnp4!utzoo seismo!mnetor utai hcr decvax!utcsri } !lsuc!davejallen@uxrd1.UUCP (Jon Allen) (10/02/86)
I once tested split speeds under 4.2BSD a long long time ago. It seems
to me that it was relatively easy. I wrote a little progroam that used
ioctl to set two different speeds once I had logged in. I believe the
4.2 terminal control structure had capabilities for separate input and
output speeds. I am not sure this is true in SYS V. Then I changed the
speeds on the terminal. You need two things to do this; a multiplexor
on your computer that can handle split speeds, and a terminal that can
handle split speeds. Of course to do it nicely at least getty would
have to be hacked.
-Jon Allen
{...}!ihnp4!acpy01!jallenperry@hpfcdc.HP.COM (Perry Scott) (10/02/86)
>The machine can output genuine 19200, >but loses characters when processing input on a tty line at >faster than 1200. This means that function keys on a VT-100 >compatible (which transmit a multi-char sequence beginning >with ESC) sometimes aren't properly received. This sounds like you aren't using a buffered interface. This kind of problem occurs when the CPU can't service the interrupt in time. The best solution is to buy a buffered interface - it's probably cheaper than spending time to make the stty/driver hacks. >Obviously I'd have to hack stty(1) and getty to grok split speeds. >Are there any other gotchas I should be aware of? Yes. Your hardware has to grok the split speeds too, as well as the driver. Perry Scott ..{ihnp4,hplabs}!hpfcla!perry-s
guy@sun.UUCP (10/05/86)
> >Obviously I'd have to hack stty(1) and getty to grok split speeds. > >Are there any other gotchas I should be aware of? > > Yes. Your hardware has to grok the split speeds too, as well as the > driver. Since the system in question is V7-based, the driver presumably handles split speeds. If the hardware doesn't support them, it should ignore a request for split speeds (from the V7 manual: "...If other hardware is used, impossible speed changes are ignored."). The 4.3BSD "stty" will not, in general, *set* split speeds (there is an undocumented "gspeed" option that sets the input speed to 300 baud and the output speed to 9600 baud), but it will report them properly. I think this "stty" is descended from the V7 "stty", so that one may do the same. The V7 "getty"'s speed tables were compiled into the program, so you'd need source to hack them. I believe they were just specified as the five fields in the "sgttyb" structure, so the input and output speeds were separate and it wouldn't have to be changed to handle split speeds. By and large, few other programs set the speed or look at it, so they wouldn't have to be changed. "curses" and "vi" look at the output speed to determine how quickly repainting takes place, so they wouldn't have to be changed either. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)