Wolfgang Denk wrote: > Dear Guennadi Liakhovetski, > > In message <pine.lnx.4.64.0901302206180.4...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot