[U-Boot] [PATCH v3] Add 16bpp BMP support

[Mark Jackson]

Wolfgang Denk wrote:
> Dear Guennadi Liakhovetski,
> 
> In message <Pine.LNX.4.64.0901302206180.4617 at axis700.grange> you wrote:
>> platform-specific types and code. So, looking at this your patch - do we 
>> really need the one more CONFIG_ define for CONFIG_BMP_16BPP? What are the 
>> drawbacks of adding your code unconditionally? extra 100 bytes for all 
>> configurations using LCD?
> 
> Yes.

In fact, there's almost a case for adding *even more* #defines to remove 
the 1bpp and 8bpp code when you've #defined your board to use 16bpp.

> 
>> Another question - do you really need 16bpp bmp? I saw a discussion on 
>> this list, that other picture formats should not be added to U-Boot - you 
>> can easily convert any format to bmp. Are 256 colours really not enough 
>> for you? I used a real photo today as a test image, converted to an 8-bit 
>> bmp. It looked well enough on my qvga. And normally you use this lcd code 
>> to display a splashscreen, which is usually a computer-generated image, so 
>> 256 colours should suffice? Although, I am not an expert in graphical 
>> desing.
> 
> I can understand that 8 bpp doe snot satisfy anoybode with more than
> just basic graphics needs.

Exactly ... in my case, I boot up linux which is also using 16bpp.  My 
aim was to have the bootsplash image displayed by u-boot, and remain 
*intact* throughtout the linux boot sequence.  Switching from 8bpp (in 
u-boot) to 16bpp (in linux) would cause some nasty screen corruption, 
and require the image to be re-displayed, which kind of spoils the whole 
concept of a boot logo.

> 
>> If we really add more bmp formats, we also get more combinations like of 
>> bmp / lcd:
> 
> Not necessarily. We can always request that bitmap images match the
> "natural" color depth of the display. It makes no sense to send a 16
> bpp image to a 1 bpp display, nor does it vice versa.

As far as I understand, U-boot was not written be some fully-fledged OS 
... rather to just allow a smooth transition from power-on to "real" OS. 
  Thus we only need to support some fairly "simple" combinations of 
options, but enough to keep the majority happy.

I guess up till now, 1bpp and 8bpp have been sufficient.

> 
>> BMP	LCD
>> 1-bit	1-bit
>> 8-bit	1-bit
>> 16-bit	1-bit
>> 1-bit	8-bit
>> ...
>>
>> if we really want to go that way, maybe better break this code into 
>> several functions for different format conversions?
> 
> We do NOT want to do everything that is possible, but only what is
> reasonable.

Exactly ... otherwise where do you stop ?  JPG, GIF, TIFF, PNG, etc ? 
We're *only* meant to be showing a simply boot up image (not view lots 
of different sized photos or movies !!), in a very controlled 
environment (i.e. no "user" options ... just what the designers want / 
require).

Regards
Mark