All of lore.kernel.org
 help / color / mirror / Atom feed
From: Francesco Mandracci <francesco.mandracci@primaelectronics.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [PATCH] computation of framebuffer palette for 8bpp lcd bitmaps
Date: Fri, 16 Sep 2005 15:52:48 +0200	[thread overview]
Message-ID: <432ACE30.9000504@primaelectronics.com> (raw)

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

             reply	other threads:[~2005-09-16 13:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-16 13:52 Francesco Mandracci [this message]
2005-09-21 13:28 ` [U-Boot-Users] [PATCH] computation of framebuffer palette for 8bpp lcd bitmaps Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=432ACE30.9000504@primaelectronics.com \
    --to=francesco.mandracci@primaelectronics.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.