Subject: Re: rcons glue for new driver
To: Andy Doran <ad@psn.ie>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: port-pmax
Date: 02/21/1999 19:21:34
>> I need a little advice on the new PX/PXG etc. driver. This won't work with
>> rcons (since it's not a raster device) without quite a bit of hacking to
>> rcons, and since rcons is used for more than 1 platform, it seems like a
>> bad idea. Do we actually keep a 'localised' version in the pmax tree?

>I think the answer is no.

That's correct. and rcons will (barring a miracle) be what we ship as
console code for 1.4, so it'd be nice to have PX/PXG code that can 
work with both.

Just for 1.4, I'd be happy to split rcons into a tty-emulator layer
and a bitblt layer, with function-pointer calls from the tty-emulator
to a character-painting layer.  Those could, in principle, just use a
`struct wsdispla_emulops'.  If we add a rcons new initialization
hook that takes such a struct,  the existing rcons attach code could
just automagically supply one. I think we could fold that back into the
tree.

Asking Matthias Drochner is probably the right thing to do, though.



>> Furthermore, the driver seems like an *ideal* candidate for wscons, which
>> has hooks for accelerated boards. As far as I remember, this would require
>> a rewrite of the lk201 stuff. What's the situation here?

yes, it is an  ideal candidate.

>MI z85C30 based wscons kbd/mouse drivers are imcomplete but in useful
>state for 3MIN and 3MAX+.  Consult 'M.Drochner@fz-juelich.de' about
>this subject. 

True, but these use the so-called `mi' zs driver, and Matthias says
they dont support modem control on the TC serial ports.  That's a
worry.  It also leaves the Personal DEcstations, and teh 5000/200, and
3100 out in the cold.

>For PX wscons integration, it'd be a good start point to exploit
>'sys/dev/tc/cfb.c';
>
>        s/cfb/px/g
>        s/rop_/stic_/
>
>Then build STIC version of raster console routines for px_emulops and
>hack px_intr().  12x22 'gallant19' font is readily available.

That's a good start, but we really need to abstract the VDAC (or
ramdac) controller out of that code, instead of replicating it 3 times
-- or 4 times, if you count i860 boards with 24-bit colour via 3 VDACs.