>Number:         4438
>Category:       port-pmax
>Synopsis:       pmax kernel glass-tty console code is broken
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    gnats-admin (GNATS administrator)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Nov  5 20:05:02 1997
>Last-Modified:
>Originator:     Jonathan Stone
>Organization:
	
>Release:        NetBSD 1.3_ALPHA; also NetBSD 1.2.
>Environment:
	
System: NetBSD Reno.DSG.Stanford.EDU 1.3_ALPHA NetBSD 1.3_ALPHA (GENERIC) #0: Tue Oct 28 21:58:43 PST 1997 jonathan@Reno.DSG.Stanford.EDU:/reno/compile/GENERIC pmax


>Description:

   The design of the pmax glass-tty console code (derived
from the 4.4BSD/pmax console code) is buggy.

Consider a pmax using a framebuffer console  on top of rcons.

The pmax kernel sets up the dev_t in the MI console code's cntab to
have a dev_t entry of the keyboard serial driver.  All console output
thus goes down to the keyboard driver -- sys/arch/pmax/dev/dc.c,
sys/arch/pmax/tc/scc.c, or sys/arch/pmax/dev/dtop.c.

The serial-driver output routines all have a special check to see if a
raster console is active. If this test succeeds, the serial driver
pulls chars off the device input queue and passes them one-by-one into
the console output routine.

This results 


>How-To-Repeat:

	Boot a pmax with a framebuffer console. Log into the console.

	* Notice that the console tty size is zero, even though
	  adding debugging to rcons.c and the MI console code shows
	  that the struct tty for rcons computes the  correct size
	  from the framebuffer pixel dimensions and the fixed font size.

	* Try doing a `cu' to the tty line wiht the keyboard.
	  Note how typed characters get printed on the framebuffer console.

	* note how screenblank doesn't notice keyboard input and so never
	  turns the screen back on after it blanks.

>Fix:

I think the correct fix is to change the rcons code so that the dev_t
in the MI console code's console struct points at rcons' cdevsw
entries, and to have all console output go via the rcons driver.  That
is conceptually correct: rcons console I/O should go through an
`rcons' device, so as to get tty size and modification-times correct.
It should also eliminate much of the special-casing in the serial
keyboard-input device drivers, which would either call a
pseudo-interrupt routine to deliver input keyboard chars to rcons, or
do an input-side version of the hack they do now.


I haven't yet figured out how to glue the bottom-half input and char
echo into this design, though.  i have patches, but they result in
leaving erroneous block cursors as `cursor droppings' on the screen,
one cursor for each char of type-ahead I send while output is being
displayed.  (eg.., from a long ls).

I'd do what the Sparc port does wiht rcons input, but I can't figure
out how the Sparc port glues this all together.  The pmax port doesn't
have a single `keyboard device' like sun4s do, which seems to
complicate this. (asking for help hasn't gotten any answers yet.)


For the 1.3 release, I suggest perpetuating and extending the 4.4BSD
kludge: add a check to each serial driver's open routine, and if a
serial console is active and the open is for the keyboard port, then
set the tty size of the keyboard's `struct tty' from the rcons device.
That will at least set the correct tty size for tty-aware applications
running on rcons. This is important for using sysinst as the
installation tool for 1.3.
>Audit-Trail:
>Unformatted: