atyfb (2.6): Add RGB565 support
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
@@ -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
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
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
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
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
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
@@ -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
@@ -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
@@ -3,7 +3,7 @@ HOST_TARGET = pnmtohex -LIBS += -lnetpnm -lnetpbm -lnetpgm -lnetppm +LIBS += -lnetpbm include $(TOPDIR)/Rules.make
visops/directcolor.c +17 -3
@@ -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 ;
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