Just a quick update.
On Sun, 22 Sep 2013, Maciej W. Rozycki wrote:
> As to the PMAG-AA board itself -- well, this is indeed a very rare item,
> but I happen to have a specimen. To support it properly I'll first have
> to wire it to a monitor somehow though; signalling is standard, 1.0 Vpp
> composite monochrome, but what looks to me like a type F connector is used
> for video output, quite unusually for a graphics card (and for DEC itself
> too as 3W3 was their usual video socket). It looks to me like converting
> it to BNC and then a standard DE-15 VGA connector (via the green line)
> will be the easiest way to get image produced by the adapter on a
> contemporary monitor (sync-on-green required of course, but with LCD
> devices being the norm now that seems less of a problem these days).
So more weirdly even that's actually a TNC connector rather than a type F
one. I've got a suitable TNC->BNC adapter now (although regrettably such
adapters seem to be available as 50Ω parts only; hopefully any distortion
won't be too significant or maybe my digital monitor will even be able to
compensate it, but at £1.76 (~$2.64) per item it's certainly worth trying
before resorting to the original DEC TNC->BNC cable still apparently
available from second-hand part suppliers at ~£80/$120 per a mere 1ft
part) and a BNC->DE-15 cable is on the way.
> > --- a/drivers/video/pmag-aa-fb.c
> > +++ b/drivers/video/pmag-aa-fb.c
> > @@ -459,7 +459,7 @@ static int __init init_one(int slot)
> > return -EINVAL;
> > printk(KERN_INFO "fb%d: %s frame buffer in TC slot %d\n",
> > - GET_FB_IDX(ip->info.node), ip->info.modename, slot);
> > + ip->info.node, ip->info.modename, slot);
> > return 0;
> > }
> Thanks, but the changes required are actually much more than that -- the
> driver has never been converted to the modern TURBOchannel API. I have
> now dug out an old patch I was working on back in 2006 to convert this
> driver as well as drivers/video/maxinefb.c. I'll try to complete the two
> drivers as soon as possible (unfortunately I can't test the latter at all;
> it's for an onboard graphics adapter of another DECstation model),
> although I now remember the main reason I didn't complete them back then
> was they used an old internal API that was removed and no suitable
> replacement provided. I need to investigate again what that actually was
> though (hw cursor probably).
So I think I've got all the basic stuff covered now, including a change
similar to your proposal as well as a conversion to the driver model/new
TURBOchannel support infrastructure. But what I remembered is actually
right, the issue is wiring hardware cursor support into fbcon. The driver
uses its own display_switch structure with its own aafbcon_cursor handler
to use the twin onboard Bt431 chips for cursor generation (there's also
aafbcon_set_font that pokes at the Bt431s for cursor dimension changes).
I need to figure out what the best way will be to make the fbcon subsystem
support such an arrangement and that'll take me a little bit yet, so
please be patient.
Note that the board is weird enough to have a 1-bit (true monochrome)
graphics plane, however the Bt455 used by the MX graphics adapter for
screen image generation is a 4-bit grey-scale video RAMDAC (only the LSB
inputs of its pixel port are wired to the graphics plane) and the twin
Bt431s use the overlay plane to produce a 2-bit grey-scale cursor. So we
do want to use the hardware cursor to be able to make it prominent among
the characters displayed throughout the screen and a software-generated
cursor cannot really substitute what hardware provides.