Re: [PATCH 2/2] framebuffer: Remove pmag-aa-fb

Adding Maciej and linux-mips

On Fri, Sep 20, 2013 at 3:53 AM, Joe Perches [off-list ref] wrote:

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

Joe, Geert --

 Can we please wait with that a few days?  I've been reviving DECstation 
bits recently but the generic stuff took priority (thankfully little 
bitrot there, the port generally works, except from the 64-bit mode).  I 
think it'll make more sense if we have an incremental diff in the repo 
rather than a complete removal, followed with a readdition with necessary 
adjustments.

Adding Maciej and linux-mips

 Thanks for (re-)pinging, I've been trying to push things forwards as time 
permits.

  Maciej

On Fri, 2013-09-20 at 19:18 +0100, Maciej W. Rozycki wrote:

Joe, Geert --

Hi Maciej

Can we please wait with that a few days?  I've been reviving DECstation 
bits recently but the generic stuff took priority (thankfully little 
bitrot there, the port generally works, except from the 64-bit mode).  I 
think it'll make more sense if we have an incremental diff in the repo 
rather than a complete removal, followed with a readdition with necessary 
adjustments.

Good for you.

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)

This one's been dead for about that long too so
what's a little more time...

The commit that removed it was:
-------------------
commit c708093f8164011d01eb3bbdf7d61965f283ee0e
Author: James Simmons [off-list ref]
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;
 }

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).

 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

On Sun, Sep 22, 2013 at 10:09 PM, Maciej W. Rozycki
[off-list ref] 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

On Sun, 22 Sep 2013, Geert Uytterhoeven wrote:

quoted

 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

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.

quoted

--- 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

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.