Skip to contentSkip to conversation

atyfb (2.6): Add RGB565 support

PATCH In review Ville Syrjälä 3 participants 7 messages May 11, 2004 – May 14, 2004 Framebuffer layer

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 atyfb (2.6): Add RGB565 support

This patch adds RGB565 support to atyfb.

Signature · 3 lines
Ville Syrjälä
[email protected]
http://www.sci.fi/~syrjala/
drivers/video/aty/atyfb.h +1 -0
diff -urN linux-orig/drivers/video/aty/atyfb.h linux/drivers/video/aty/atyfb.h
@@ -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;
drivers/video/aty/atyfb_base.c +56 -21

134 lines not on this page · raw message

#1 lore raw
Quoted 1 line · 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 -- [email protected]

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

#2 lore raw
Quoted 6 lines · Geert Uytterhoeven
Quoted 1 line · 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.

Signature · 10 lines
Ville Syrjälä
[email protected]
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
#3 lore raw

Hi Ville,

Quoted 4 lines · On Wed, 12 May 2004, Ville [iso-8859-1] Syrjälä wrote:
Quoted 3 lines · Geert Uytterhoeven
Quoted 1 line · On Wed, 12 May 2004, Ville [iso-8859-1] Syrjälä wrote:

This patch adds RGB565 support to atyfb.

Quoted 8 lines
Quoted 3 lines

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 -- [email protected]

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

#4 lore raw
Quoted 11 lines · Geert Uytterhoeven

Hi Ville,

Quoted 8 lines · On Wed, 12 May 2004, Ville [iso-8859-1] Syrjälä wrote:
Quoted 6 lines · Geert Uytterhoeven
Quoted 1 line · 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.

Quoted 7 lines
Quoted 4 lines

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.

Signature · 10 lines
Ville Syrjälä
[email protected]
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
#5 lore raw
In reply to Geert Uytterhoeven
Quoted 26 lines · Geert Uytterhoeven

Hi Ville,

Quoted 11 lines · On Wed, 12 May 2004, Ville [iso-8859-1] Syrjälä wrote:
Quoted 8 lines · Geert Uytterhoeven
Quoted 3 lines · 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?

Quoted 9 lines
Quoted 3 lines

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.

Quoted 4 lines

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

clut.c +24 -1
diff -urNX dontdiff2 fbtest.old/clut.c fbtest/clut.c
@@ -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) {
include/clut.h +1 -0
diff -urNX dontdiff2 fbtest.old/include/clut.h fbtest/include/clut.h
@@ -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);
 
pnmtohex/Makefile +1 -1
diff -urNX dontdiff2 fbtest.old/pnmtohex/Makefile fbtest/pnmtohex/Makefile
@@ -3,7 +3,7 @@
 
 HOST_TARGET = pnmtohex
 
-LIBS += -lnetpnm -lnetpbm -lnetpgm -lnetppm
+LIBS += -lnetpbm
 
 include $(TOPDIR)/Rules.make
 
visops/directcolor.c +17 -3
diff -urNX dontdiff2 fbtest.old/visops/directcolor.c fbtest/visops/directcolor.c
@@ -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;
#6 lore raw
Quoted 8 lines · John Zielinski
Quoted 5 lines · Geert Uytterhoeven

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

Quoted 5 lines

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

Signature · 10 lines
Ville Syrjälä
[email protected]
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