Linux Framebuffer Layer development

* Re: [PATCH 2/2] framebuffer: Remove pmag-aa-fb
From: Maciej W. Rozycki @ 2013-09-22 20:09 UTC (permalink / raw)
  To: Joe Perches
  Cc: Geert Uytterhoeven, Jean-Christophe Plagniol-Villard,
	Tomi Valkeinen, Linux Fbdev development list,
	linux-kernel@vger.kernel.org, Linux MIPS Mailing List
In-Reply-To: <1379702587.2301.12.camel@joe-AO722>

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

^ permalink raw reply