Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1a 12/4/83; site rlgvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!houxz!vax135!floyd!cmcl2!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.wanted,net.unix-wizards
Subject: Re: Wanted: info on ONYX i/o
Message-ID: <1963@rlgvax.UUCP>
Date: Wed, 30-May-84 11:45:10 EDT
Article-I.D.: rlgvax.1963
Posted: Wed May 30 11:45:10 1984
Date-Received: Sat, 2-Jun-84 07:25:54 EDT
References: <7715@gatech.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 47

> I'm trying to use IOCTL to configure a port on our Onyx UNIX system
> to have even parity output generation, and NO PARITY input detection.
> There's supposedly an i_flag in the termio struct called INPCK that,
> if not set, will turn off input parity detection.

> For some reason (perhaps it's a bug with Onyx?), it's not working.
> Any help or insights would be greatly appreciated.

The trick here may be that in most systems there are two cooperating pieces
of equipment in parity handling; the terminal multiplexer and the computer.
The c_cflag bits PARENB and PARODD control the terminal multiplexer; if
PARENB is off the multiplexer doesn't generate output parity or check
input parity, and if it is on it generates output parity and checks input
parity.  (I don't know of any hardware that permits you to generate parity
but not check it.)  If PARENB is set, even parity is generated and checked
for if PARODD is off, and odd parity is generated and checked for if PARODD
is on.  However, if the multiplexer detects a character with invalid parity
it usually just hands the character to the processor with a flag saying
"bad parity".  The INPCK bit controls whether the computer pays any attention
to that bit or not (and has no effect on the terminal multiplexer).

I don't know whether the particular terminal multiplexor Onyx uses strips
the parity bit off if parity checking is enabled or not.  It may depend on
the particular UART (or equivalent) chip used by the multiplexor, but then
again all such chips may do the same thing.  By "it's not working", do you
mean that the eighth bit is being stripped off on input (in which case
make sure you're clearing the ISTRIP flag in the c_iflags word), or that
it's reporting parity errors (either by throwing away input characters
or marking them with PARMRK), or something else?

While we're on the subject of parity, does anybody out there interpret the
passage:

	EVENP	0000200 Even parity allowed on input (most terminals)
	ODDP	0000100 Odd parity allowed on input

from the V7 and 4.1BSD manual page TTY(4) as meaning "if the EVENP bit is
set, even parity will be checked for on input *but* the system will not
generate even parity on output"?  Somebody was rather insistent on that
being the correct interpretation, and no amount of logic could dissuade him
from that conclusion.  It seems kinda silly to me - if taken that literally,
it means that V7/4.1BSD systems can't generate parity on output at all
(there's no "Even parity generated on output" bit in the sg_flags word, or
anywhere else).

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy