Terminal output: parity, 7 vs. 8 bits, etc.

[Joe Kelsey]

I realize that this may be a new subject of controversy, but it is
probably a subject that should be faced soon.  I just received my brand
new VT220 (no flames about the keyboard or packaging please - I believe
that a keyboard is something that grows on you and is also a personal
preference, so let's not discuss that here!) and have been going
through the manual learning about it.  Probably the most important
feature of the terminal is that it is the first terminal which supports
true 8-bit ASCII according to the ANSI standard.  Now, we all know that
UNIX supports only a 7 bit data path to the terminals (unless you use
RAW or LITOUT mode), so it is not likely to be easy to support the
VT220/240 in 8-bit mode very quickly.  However, I think that it is
worth bringing up this topic to see whether or not it would be
worthwhile changing the tty driver to support a general 8 bit data path
in cooked mode.

As I was paging through the tty driver looking at all of the
horrible-ness of the code, I realize that the 7-bit input path is
really a V6 hang-over and will require a monumental effort to expunge.
Probably the tty driver should be completely rewritten, but I don't
want to do it.  I did notice one interesting thing - at least in
Berkeley UNIX, you ALWAYS get 7 bit characters with some sort of parity
on output!  Unless you choose RAW or LITOUT, both the dz and dh drivers
will set 7bits, even or odd parity on output.  Why?  Almost every
terminal I have ever set up I alwyas set to ignore parity, and to
generate either no parity or space parity on input (actually output
from the terminal, but sides are confusing here).  Is there any real
reason to continue this?  I have a proposed change for both the dz and
dh drivers, in the xxparam() function which would only set parity if
the user requested EITHER EVENP OR ODDP, but no if both were set or
neither set.  The change is simple, just adding an if statment and else
clause, but I was wondering what effect this would have on terminal
I/O, if any.  Here is the change:

*** /sys/vaxuba/dz.c	Tue Nov  1 21:24:09 1983
--- dz.c	Thu Mar 22 14:37:35 1984
***************
*** 395,400
  	if (tp->t_flags & (RAW|LITOUT))
  		lpr |= BITS8;
  	else
  		lpr |= (BITS7|PENABLE);
  	if ((tp->t_flags & EVENP) == 0)
  		lpr |= OPAR;

--- 395,415 -----
  	if (tp->t_flags & (RAW|LITOUT))
  		lpr |= BITS8;
  	else
+ #ifdef parity_fix
+ 	/*
+ 	 * Don't actually enable output parity unless the user specifically
+ 	 * request it by setting either EVENP or ODDP (but not both!)
+ 	 * This may help support actual 8-bit output to terminals, but the
+ 	 * issue of 8-bit input is still left dangling.  Basically, my
+ 	 * this is to support the VT220 better.  jmk 22-mar-84
+ 	 */
+ 	if ((tp->t_flags&(EVENP|ODDP))==EVENP
+ 	 || (tp->t_flags&(EVENP|ODDP))==ODDP) {
+ #endif parity_fix
  		lpr |= (BITS7|PENABLE);
+ #ifdef parity_fix
+ 	 } else
+ 	 	lpr |= BITS8;
+ #endif parity_fix
  	if ((tp->t_flags & EVENP) == 0)
  		lpr |= OPAR;

This is the only place in the entire tty structure that parity is
mentioned.  The infamous 'partab' structure is completely useless as a
parity table in Berkeley UNIX.  There are EXACTLY three references to
the parity table in the tty driver, all of which use it to select the
character class and discard the parity information.  In fact, the
kernel never checks the parity of the character after receiving it from
the device driver.  The kernel relies on the device to check and
generate parity.  So, why do we need to burden the kernel with any
parity information at all?  I personally don't want to figure out how
to make the input path 8 bits in cooked mode, but setting up an eight
bit output path is trivial, if my patch above works.

So, let's hear it.  Are there any defenders of a 7 bit input path, or
should someone think about making the terminal I/O 8 bits in each
direction?  Is parity useful in anything but noisy line situations?  I
would like to hear any and all opinions on this subject.  People who
want to flame about the VT2xx can send their comments to /dev/null.

/Joe