[PATCH] atyfb (2.6): Add RGB565 support

[PATCH] atyfb (2.6): Add RGB565 support

[Ville Syrjälä]

[-- Attachment #1: Type: text/plain, Size: 109 bytes --]

This patch adds RGB565 support to atyfb.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/

[-- Attachment #2: atyfb-2.6-rgb565.patch --]
[-- Type: text/plain, Size: 4182 bytes --]

diff -urN linux-orig/drivers/video/aty/atyfb.h linux/drivers/video/aty/atyfb.h
--- linux-orig/drivers/video/aty/atyfb.h	2004-05-11 23:45:00.524832384 +0300
+++ linux/drivers/video/aty/atyfb.h	2004-05-11 23:52:08.142824568 +0300
@@ -116,6 +116,7 @@
 
 struct atyfb_par {
 	struct aty_cmap_regs *aty_cmap_regs;
+	struct { u8 red, green, blue; } palette[256];
 	const struct aty_dac_ops *dac_ops;
 	const struct aty_pll_ops *pll_ops;
 	unsigned long ati_regbase;
diff -urN linux-orig/drivers/video/aty/atyfb_base.c linux/drivers/video/aty/atyfb_base.c
--- linux-orig/drivers/video/aty/atyfb_base.c	2004-05-11 23:45:00.532831168 +0300
+++ linux/drivers/video/aty/atyfb_base.c	2004-05-12 00:07:24.822468080 +0300
@@ -683,6 +683,8 @@
 	xoffset = var->xoffset;
 	yoffset = var->yoffset;
 	bpp = var->bits_per_pixel;
+	if (bpp == 16)
+		bpp = (var->green.length == 5) ? 15 : 16;
 	sync = var->sync;
 	vmode = var->vmode;
 
@@ -702,12 +704,18 @@
 		    HOST_8BPP | SRC_8BPP | DST_8BPP |
 		    BYTE_ORDER_LSB_TO_MSB;
 		dp_chain_mask = DP_CHAIN_8BPP;
-	} else if (bpp <= 16) {
+	} else if (bpp <= 15) {
 		bpp = 16;
 		pix_width = CRTC_PIX_WIDTH_15BPP;
 		dp_pix_width = HOST_15BPP | SRC_15BPP | DST_15BPP |
 		    BYTE_ORDER_LSB_TO_MSB;
 		dp_chain_mask = DP_CHAIN_15BPP;
+	} else if (bpp <= 16) {
+		bpp = 16;
+		pix_width = CRTC_PIX_WIDTH_16BPP;
+		dp_pix_width = HOST_16BPP | SRC_16BPP | DST_16BPP |
+		    BYTE_ORDER_LSB_TO_MSB;
+		dp_chain_mask = DP_CHAIN_16BPP;
 	} else if (bpp <= 24 && M64_HAS(INTEGRATED)) {
 		bpp = 24;
 		pix_width = CRTC_PIX_WIDTH_24BPP;
@@ -1078,7 +1086,6 @@
 		var->transp.offset = 0;
 		var->transp.length = 0;
 		break;
-#if 0
 	case CRTC_PIX_WIDTH_16BPP:	/* RGB 565 */
 		bpp = 16;
 		var->red.offset = 11;
@@ -1090,7 +1097,6 @@
 		var->transp.offset = 0;
 		var->transp.length = 0;
 		break;
-#endif
 	case CRTC_PIX_WIDTH_24BPP:	/* RGB 888 */
 		bpp = 24;
 		var->red.offset = 16;
@@ -2521,46 +2527,75 @@
 	u_int transp, struct fb_info *info)
 {
 	struct atyfb_par *par = (struct atyfb_par *) info->par;
-	int i, scale;
+	int i, depth;
 	u32 *pal = info->pseudo_palette;
 
+	depth = info->var.bits_per_pixel;
+	if (depth == 16)
+		depth = (info->var.green.length == 5) ? 15 : 16;
+
 	if (par->asleep)
 		return 0;
-	if (regno > 255)
+
+	if (regno > 255 ||
+	    (depth == 16 && regno > 63) ||
+	    (depth == 15 && regno > 31))
 		return 1;
+
 	red >>= 8;
 	green >>= 8;
 	blue >>= 8;
+
+	par->palette[regno].red = red;
+	par->palette[regno].green = green;
+	par->palette[regno].blue = blue;
+
+	if (regno < 16) {
+		switch (depth) {
+		case 15:
+			pal[regno] = (regno << 10) | (regno << 5) | regno;
+			break;
+		case 16:
+			pal[regno] = (regno << 11) | (regno << 5) | regno;
+			break;
+		case 24:
+			pal[regno] = (regno << 16) | (regno << 8) | regno;
+			break;
+		case 32:
+			i = (regno << 8) | regno;
+			pal[regno] = (i << 16) | i;
+			break;
+		}
+	}
+
 	i = aty_ld_8(DAC_CNTL, par) & 0xfc;
 	if (M64_HAS(EXTRA_BRIGHT))
 		i |= 0x2; /* DAC_CNTL | 0x2 turns off the extra brightness for gt */
 	aty_st_8(DAC_CNTL, i, par);
 	aty_st_8(DAC_MASK, 0xff, par);
-	scale = (M64_HAS(INTEGRATED) && info->var.bits_per_pixel == 16) ? 3 : 0;
+
+	if (M64_HAS(INTEGRATED)) {
+		if (depth == 16) {
+			red = par->palette[regno>>1].red;
+			blue = par->palette[regno>>1].blue;
+			regno <<= 2;
+		} else if (depth == 15) {
+			regno <<= 3;
+		}
+	}
+		
 #ifdef CONFIG_ATARI
-	out_8(&par->aty_cmap_regs->windex, regno << scale);
+	out_8(&par->aty_cmap_regs->windex, regno);
 	out_8(&par->aty_cmap_regs->lut, red);
 	out_8(&par->aty_cmap_regs->lut, green);
 	out_8(&par->aty_cmap_regs->lut, blue);
 #else
-	writeb(regno << scale, &par->aty_cmap_regs->windex);
+	writeb(regno, &par->aty_cmap_regs->windex);
 	writeb(red, &par->aty_cmap_regs->lut);
 	writeb(green, &par->aty_cmap_regs->lut);
 	writeb(blue, &par->aty_cmap_regs->lut);
 #endif
-	if (regno < 16)
-		switch (info->var.bits_per_pixel) {
-		case 16:
-			pal[regno] = (regno << 10) | (regno << 5) | regno;
-			break;
-		case 24:
-			pal[regno] = (regno << 16) | (regno << 8) | regno;
-			break;
-		case 32:
-			i = (regno << 8) | regno;
-			pal[regno] = (i << 16) | i;
-			break;
-		}
+
 	return 0;
 }
 

Re: [PATCH] atyfb (2.6): Add RGB565 support

[Geert Uytterhoeven]

On Wed, 12 May 2004, Ville [iso-8859-1] Syrjälä wrote:
> This patch adds RGB565 support to atyfb.

Nice! Have you tried fbtest on it?

I once tried to implement it myself, but it didn't work reliably.

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


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [PATCH] atyfb (2.6): Add RGB565 support

[Ville Syrjälä]

On Wed, May 12, 2004 at 11:11:21AM +0200, Geert Uytterhoeven wrote:
> On Wed, 12 May 2004, Ville [iso-8859-1] Syrjälä wrote:
> > This patch adds RGB565 support to atyfb.
> 
> Nice! Have you tried fbtest on it?
> 
> I once tried to implement it myself, but it didn't work reliably.

I just tried fbtest and most tests look ok. The penguin images are wrong 
(green instead of white stuff aroung the penguin) and the test009 looks 
wrong too. Are you sure fbtest is doing the right thing with rgb565 
directcolor visuals? DirectFB or mplayer don't have any problems.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [PATCH] atyfb (2.6): Add RGB565 support

[Geert Uytterhoeven]

	Hi Ville,

On Wed, 12 May 2004, Ville [iso-8859-1] Syrjälä wrote:
> On Wed, May 12, 2004 at 11:11:21AM +0200, Geert Uytterhoeven wrote:
> > On Wed, 12 May 2004, Ville [iso-8859-1] Syrjälä wrote:
> > > This patch adds RGB565 support to atyfb.
> >
> > Nice! Have you tried fbtest on it?
> >
> > I once tried to implement it myself, but it didn't work reliably.
>
> I just tried fbtest and most tests look ok. The penguin images are wrong
> (green instead of white stuff aroung the penguin) and the test009 looks
> wrong too. Are you sure fbtest is doing the right thing with rgb565
> directcolor visuals? DirectFB or mplayer don't have any problems.

It's always possible there's a bug in fbtest w.r.t. 565 handling, but I didn't
see it.

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


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id%62&alloc_ida84&op=click

Re: [PATCH] atyfb (2.6): Add RGB565 support

[Ville Syrjälä]

On Thu, May 13, 2004 at 11:22:01AM +0200, Geert Uytterhoeven wrote:
> 	Hi Ville,
> 
> On Wed, 12 May 2004, Ville [iso-8859-1] Syrjälä wrote:
> > On Wed, May 12, 2004 at 11:11:21AM +0200, Geert Uytterhoeven wrote:
> > > On Wed, 12 May 2004, Ville [iso-8859-1] Syrjälä wrote:
> > > > This patch adds RGB565 support to atyfb.
> > >
> > > Nice! Have you tried fbtest on it?
> > >
> > > I once tried to implement it myself, but it didn't work reliably.
> >
> > I just tried fbtest and most tests look ok. The penguin images are wrong
> > (green instead of white stuff aroung the penguin) and the test009 looks
> > wrong too. Are you sure fbtest is doing the right thing with rgb565
> > directcolor visuals? DirectFB or mplayer don't have any problems.
> 
> It's always possible there's a bug in fbtest w.r.t. 565 handling, but I didn't
> see it.

It has the same problems on aty128fb so either that driver is broken too 
or the fault lies with fbtest. On matroxfb RGB565 is fine but matroxfb 
uses a truecolor visual.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id%62&alloc_ida84&op=click

Re: [PATCH] atyfb (2.6): Add RGB565 support

[John Zielinski]

[-- Attachment #1: Type: text/plain, Size: 1201 bytes --]

Geert Uytterhoeven wrote:

>	Hi Ville,
>
>On Wed, 12 May 2004, Ville [iso-8859-1] Syrjälä wrote:
>  
>
>>On Wed, May 12, 2004 at 11:11:21AM +0200, Geert Uytterhoeven wrote:
>>    
>>
>>>On Wed, 12 May 2004, Ville [iso-8859-1] Syrjälä wrote:
>>>      
>>>
>>>>This patch adds RGB565 support to atyfb.
>>>>        
>>>>
>>>Nice! Have you tried fbtest on it?
>>>
>>>I once tried to implement it myself, but it didn't work reliably.
>>>      
>>>
>>I just tried fbtest and most tests look ok. The penguin images are wrong
>>(green instead of white stuff aroung the penguin) and the test009 looks
>>wrong too. Are you sure fbtest is doing the right thing with rgb565
>>directcolor visuals? DirectFB or mplayer don't have any problems.
>>    
>>
>
>It's always possible there's a bug in fbtest w.r.t. 565 handling, but I didn't
>see it.
>  
>

It's a bug in fbtest's directcolor routines.   Directcolor sets the clut 
using using the min of the RGB sizes so 565 becomes 555.  The problem is 
that tests 4, 8 and 9 use the buffer as 565 (VISUAL_GENERIC & 
VISUAL_TRUECOLOR) and the directcolor routines don't reset the clut to 
it's full range.  Fix attached.

John


[-- Attachment #2: fbtest_565_fix --]
[-- Type: text/plain, Size: 2903 bytes --]

diff -urNX dontdiff2 fbtest.old/clut.c fbtest/clut.c
--- fbtest.old/clut.c	2002-10-06 16:14:20.000000000 -0400
+++ fbtest/clut.c	2004-05-13 21:12:53.000000000 -0400
@@ -114,6 +114,29 @@
 
 
     /*
+     *  Create table with maximum dynamic range
+     */
+
+void clut_create_maximum(rgba_t *clut, u32 rlen, u32 glen, u32 blen, u32 alen)
+{
+    u32 i;
+    u32 len = max(max(rlen, glen), max(blen, alen));
+
+    Debug("clut_create_maximum: RGBA %dx%dx%dx%d\n", rlen, glen, blen, alen);
+    for (i = 0; i < len; i++) {
+	if (i < rlen)
+	    clut->r = EXPAND_TO_16BIT(i, rlen-1);
+	if (i < glen)
+    	    clut->g = EXPAND_TO_16BIT(i, glen-1);
+	if (i < blen)
+	    clut->b = EXPAND_TO_16BIT(i, blen-1);
+	if (i < alen)
+	    clut->a = (alen-1) ? EXPAND_TO_16BIT(i, alen-1) : 0xffff;
+	clut++;
+    }
+}
+
+    /*
      *  Create a linear ramp
      */
 
@@ -158,7 +181,7 @@
 	clut_create_rgbcube(clut, 4, 4, 4);
     } else if (idx_len >= 32) {
 	clut_create_rgbcube(clut, 3, 3, 3);
-	/* FIXME: still 3 entries left */
+	/* FIXME: still 5 entries left */
     } else if (idx_len >= 16) {
 	memcpy(clut, clut_console, sizeof(clut_console));
     } else if (idx_len >= 8) {
diff -urNX dontdiff2 fbtest.old/include/clut.h fbtest/include/clut.h
--- fbtest.old/include/clut.h	2001-05-01 10:39:20.000000000 -0400
+++ fbtest/include/clut.h	2004-05-13 20:36:03.000000000 -0400
@@ -16,6 +16,7 @@
 extern const rgba_t clut_windows[4];
 
 extern void clut_create_rgbcube(rgba_t *clut, u32 rlen, u32 glen, u32 blen);
+extern void clut_create_maximum(rgba_t *clut, u32 rlen, u32 glen, u32 blen, u32 alen);
 extern void clut_create_linear(rgba_t *clut, u32 len);
 extern void clut_init_nice(void);
 
diff -urNX dontdiff2 fbtest.old/pnmtohex/Makefile fbtest/pnmtohex/Makefile
--- fbtest.old/pnmtohex/Makefile	2003-01-20 07:58:47.000000000 -0500
+++ fbtest/pnmtohex/Makefile	2004-05-13 19:00:43.000000000 -0400
@@ -3,7 +3,7 @@
 
 HOST_TARGET = pnmtohex
 
-LIBS += -lnetpnm -lnetpbm -lnetpgm -lnetppm
+LIBS += -lnetpbm
 
 include $(TOPDIR)/Rules.make
 
diff -urNX dontdiff2 fbtest.old/visops/directcolor.c fbtest/visops/directcolor.c
--- fbtest.old/visops/directcolor.c	2003-03-18 11:53:44.000000000 -0500
+++ fbtest/visops/directcolor.c	2004-05-13 21:11:37.000000000 -0400
@@ -94,7 +94,18 @@
 
 
     /*
-     *  Truecolor/Grayscale
+     *  Truecolor/Generic
+     */
+
+static void directcolor_set_maximum(void)
+{
+    clut_create_maximum(clut, red_len, green_len, blue_len, alpha_len);
+    directcolor_update_cmap();
+}
+
+
+    /*
+     *  Grayscale
      */
 
 static void directcolor_set_linear(void)
@@ -119,11 +130,14 @@
 	case VISUAL_DIRECTCOLOR:
 	    break;
 
-	case VISUAL_GENERIC:
 	case VISUAL_GRAYSCALE:
-	case VISUAL_TRUECOLOR:
 	    directcolor_set_linear();
 	    break;
+	
+	case VISUAL_GENERIC:
+	case VISUAL_TRUECOLOR:
+	    directcolor_set_maximum();
+	    break;
 
 	default:
 	    return 0;

Re: [PATCH] atyfb (2.6): Add RGB565 support

[Ville Syrjälä]

On Thu, May 13, 2004 at 09:11:47PM -0400, John Zielinski wrote:
> Geert Uytterhoeven wrote:
> 
> >It's always possible there's a bug in fbtest w.r.t. 565 handling, but I 
> >didn't
> >see it.
> > 
> >
> 
> It's a bug in fbtest's directcolor routines.   Directcolor sets the clut 
> using using the min of the RGB sizes so 565 becomes 555.  The problem is 
> that tests 4, 8 and 9 use the buffer as 565 (VISUAL_GENERIC & 
> VISUAL_TRUECOLOR) and the directcolor routines don't reset the clut to 
> it's full range.  Fix attached.

Looks perfect with this patch.

However I just realized that the atyfb patch will not work correctly with 
partial color map updates. Revised patch coming up...

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id%62&alloc_ida84&op=click