| Message ID | 1379702587.2301.12.camel@joe-AO722 (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, 20 Sep 2013, Joe Perches wrote: > I do wonder how many of these still exist though. > > I haven't had one of those on a desk since the early > '90's (a VAXstation w/VMS and a DECstation w/Ultrix) DECstations seem virtually indestructible, so it's mostly the matter of how long people want to keep them. The only serious issue is by now they have started to suffer from dead lithium batteries that have been moulded in their DS1287A RTC chips. With Maxim taking Dallas over and then breaking their promise to produce replacements indefinitely this has become a real problem now (I did not dare trying any of the imitatations the Chinese seem to offer these days). A hack exists to rework old DS1287A (and similar) chips with a saw, a soldering iron and some skill for an external battery, but it requires some extra space around the chip and there is little in the DECstation because the DS1287A has been placed in the TURBOchannel option card area with little clearance left between the IC and any option card installed. 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). > The commit that removed it was: > ------------------- > commit c708093f8164011d01eb3bbdf7d61965f283ee0e > Author: James Simmons <jsimmons@maxwell.earthlink.net> > Date: Wed Oct 30 20:06:21 2002 -0800 > > Moved all console configuration out of arch directories into > drivers/video/console. Allow resize of a single VC via the tty layer. > Nuked GET_FB_IDX. > ------------------- > > I think you could do: > > --- > > drivers/video/pmag-aa-fb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/video/pmag-aa-fb.c b/drivers/video/pmag-aa-fb.c > index 8384248..0362fb7 100644 > --- 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). Maciej -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Sep 22, 2013 at 10:09 PM, Maciej W. Rozycki <macro@linux-mips.org> wrote: > 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). pmag-aa-fb.c still has struct display_switch (for the old drawing API) and the old fb_ops (with get_var()/get_fix()), instead of the new fb_ops (rectangular drawing API and var/fix as member data). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 22 Sep 2013, Geert Uytterhoeven wrote: > > 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). > > pmag-aa-fb.c still has struct display_switch (for the old drawing API) and the > old fb_ops (with get_var()/get_fix()), instead of the new fb_ops (rectangular > drawing API and var/fix as member data). That I got covered already in the old patch, but there was something else. Otherwise I would have pushed it along updates for pmag-ba-fb.c and pmagb-b-fb.c long ago. Maciej -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Joe, 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. Maciej -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, 2013-10-12 at 14:08 +0100, Maciej W. Rozycki wrote: [] > 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. I hope you're enjoying tinkering with old toys. Best of luck getting it going. -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/video/pmag-aa-fb.c b/drivers/video/pmag-aa-fb.c index 8384248..0362fb7 100644 --- 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; }