From mboxrd@z Thu Jan 1 00:00:00 1970 From: Detlev Zundel Date: Tue, 28 Apr 2009 10:50:41 +0200 Subject: [U-Boot] Uboot bitmap utility In-Reply-To: <23265072.post@talk.nabble.com> (Steven Zedeck's message of "Mon, 27 Apr 2009 14:05:22 -0700 (PDT)") References: <23217619.post@talk.nabble.com> <23217700.post@talk.nabble.com> <20090424180341.8275E83420E8@gemini.denx.de> <23265072.post@talk.nabble.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Steven, > Yes, I do see what U-boot is doing. I looked at bmp_logo.c and its output. > It seems that the color palette entries are all 16 bits (unsigned short). To synch up - you are trying to use the 'logo_plot' code from drivers/video/cfb_console.c, right? > For my application, I have 24 bit color, which expects each pixel to be 32 > bits, of which only 24 bits are used. So the palette, I assume, should be > unsigned longs for each color entry. Correct or am I missing something? Rather than changing this code, why don't you switch to the bmp routines (common/cmd_bmp.c + (one option) common/lcd.c) which recently got support for 16bpp displays? It may be easier to add 32-bit support here... > Did I interpret the code correctly? Does it expect 16 bits per color? It seems so.. Cheers Detlev -- ... does Linux have a better [security] track record than MS? Damn right it does. We've had fewer problems, and I think there are more people out there standing up for what's right anyway. Less PR people deathly afraid of rocking the boat. Better technology, and fewer horrid design mistakes. [Linus Torvalds] -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de