[U-Boot-Users] [PATCH] computation of framebuffer palette for 8bpp lcd bitmaps

[U-Boot-Users] [PATCH] computation of framebuffer palette for 8bpp lcd bitmaps

[Francesco Mandracci]

-- This patch is a bug fix.

-- Description on the bug: using 8 bits/pixel framebuffer, all
(splashscreen) bitmaps with palette colors whose RGB components differ
in the 5 high bits in the blue byte and/or in the 6 high bits in the
green byte do not display correctly.

-- How my patch fixes this bug: computing correctly the palette entries.

The C code fills a 16bit palette entry with 3 RGB bytes in the form

  RRRR RGGG GGGB BBBB
 [....|....|....|....]  masks: (R,G,B) (0xf800, 0x07e0, 0x001f)
  fedc ba98 7654 3210

The used bits are the highest 5 bits for the red and blue bytes and the
 6 high bits for the green byte. This did not change neither in PowerPC
nor in PXA in all cvs.sf.net revisions I've found.

The computation may be either:
colreg = ((red   & 0xf8) << 8)  /* [RRRR|Rrrr|....|....]     */
       | ((green & 0xfc) << 3)  /* [....|.GGG|GGGg|g...]     */
       | ((blue  & 0xf8) >> 3); /* [....|....|...B|BBBB]bbb. */
or:
colreg = ((red   << 8) & 0xf800)
       | ((green << 3) & 0x07e0)   /* versus " << 4" */
       | ((blue  >> 3) & 0x001f);  /* versus " >> 0" */
I choose the latter form because it's the way you adopted.

-- A way of demonstrating that the patch actually fixes something is
simply displaying such a bitmap (either splashscreen or simply as
argument to "bmp display"). For instance obtaining a 640x480 8 bpp
bitmap from http://www.dreamvideo.it/video/immagini/monoscopio.jpg: the
original code displays greys as yellowish and blues as rubbish, while
the patched code displays everything correctly.

-- (no new features)

-- CHANGELOG entry

* Corrected the computation of framebuffer palette for 8bpp lcd bitmaps
  Patch by Francesco Mandracci, 16 Sep 2005

-- CREDITS entry

N: Francesco Mandracci
E: francesco.mandracci at primaelectronics.com
P: ID=0xF6B25635
P: Fingerprint=4059 B2F9 E987 105D 00C8  3DEA 848C F56A F6B2 5635
D: Hacking PXA270

-- (no new board)

-- (no new configuration options)

-- The patch itself:
-------------------------------------------------------------------
Index: common/lcd.c
===================================================================
RCS file: /cvsroot/u-boot/u-boot/common/lcd.c,v
retrieving revision 1.5
diff -p -u -r1.5 lcd.c
--- common/lcd.c        4 Jul 2005 00:03:16 -0000       1.5
+++ common/lcd.c        16 Sep 2005 13:07:00 -0000
@@ -638,8 +638,8 @@ int lcd_display_bitmap(ulong bmp_image,
                        bmp_color_table_entry_t cte = bmp->color_table[i];
                        ushort colreg =
                                ( ((cte.red)   << 8) & 0xf800) |
-                               ( ((cte.green) << 4) & 0x07e0) |
-                               ( (cte.blue) & 0x001f) ;
+                               ( ((cte.green) << 3) & 0x07e0) |
+                               ( ((cte.blue)  >> 3) & 0x001f) ;

 #ifdef CFG_INVERT_COLORS
                        *cmap = 0xffff - colreg;
-------------------------------------------------------------------

-- (single file)

-- (single modification)

-- ok for all boards

-- modifications are at the minimum

-- thinking that the memory footprint is affected in a reasonably way

-- in order to respect the 40Kb size limit I'm not sending the very
bitmap file

Ciao
    Francesco Mandracci

[U-Boot-Users] [PATCH] computation of framebuffer palette for 8bpp lcd bitmaps

[Wolfgang Denk]

Dear Francesco,

in message <432ACE30.9000504@primaelectronics.com> you wrote:
> 
> -- CHANGELOG entry
> 
> * Corrected the computation of framebuffer palette for 8bpp lcd bitmaps
>   Patch by Francesco Mandracci, 16 Sep 2005

Thank  you  very  much  for  the  semi-perfect  patch!  I  wisch  all
submissions would be that clear and well documented.

There is only one problem:

> -- The patch itself:

It does not apply...

> -                               ( ((cte.green) << 4) & 0x07e0) |
> -                               ( (cte.blue) & 0x001f) ;
> +                               ( ((cte.green) << 3) & 0x07e0) |
> +                               ( ((cte.blue)  >> 3) & 0x001f) ;

Something (probably your mailer) crippled the white  space  (expanded
the TABs in the original source).

Applied manually, but please note this for future submissions.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
1st Old Man:  Gee, its windy today.
2nd Old Man:  No it's not... it's Thursday.
3rd Old Man:  Yeh, me too.  Let's go for a beer.