Splash image

I'm planning to review the splash image support and in order to do that my next steps should be:

1) Remove the logo support.

2) Rewrite the lcd_display_bitmap() in order to be more portable across several BPP values.

"Rodolfo Giometti" <[email protected]> wrote in message news:20070718083012.GE4836 at enneenne.com...

Quoted 4 lines

I'm planning to review the splash image support and in order to do that my next steps should be:

1) Remove the logo support.

As long as it's modular, I agreed because the two functions are nearly identical. It's important to add/remove code to keep the size down. Probably should test for a pointer to a compressed (gzip) image, uncompress, then call the bmp_display.

Quoted 2 lines

2) Rewrite the lcd_display_bitmap() in order to be more portable across several BPP values.

Keep it modular; have a bitmap_display(addr, x, y) robust to bpp that is called from an lcd_display_splash_screen(). Account for 24-bit LCDs and files. The bit-per-pixel data structure was a poor-fit with 24-bit, and I didn't even try to support colormapped files on a truecolor display. Great idea because it might save a ton of flash to display an 8bpp image on a 24bpp display.

3. If there's an overall flash savings, it would be nice to support GIF, PNG, or some other format smaller than a BMP. How complex is the parsing, and would it be a net savings on flash?

4. Account for text overlay on splash screen. There are callbacks for bootup progress, and it's nice to lcd_printf() the status to some rectangle on the screen. Even better if it scrolls or clears nicely.

5. Document and improve the videolfb ATAG. I hardcode my framebuffer to the end of RAM, don't tell linux to use that memory, and pass the info to linux. The display still flickers until you remove the re-initialization, but at least Linux won't move and therefore clobber the contents of the framebuffer.

Quoted 10 lines · Joey Oravec

"Rodolfo Giometti" <[email protected]> wrote in message news:20070718083012.GE4836 at enneenne.com...

Quoted 4 lines

I'm planning to review the splash image support and in order to do that my next steps should be:

1) Remove the logo support.

As long as it's modular, I agreed because the two functions are nearly identical. It's important to add/remove code to keep the size down. Probably should test for a pointer to a compressed (gzip) image, uncompress, then call the bmp_display.

I think we should remove it definitely... it's just doubled code.

Quoted 9 lines

Quoted 2 lines

2) Rewrite the lcd_display_bitmap() in order to be more portable across several BPP values.

Keep it modular; have a bitmap_display(addr, x, y) robust to bpp that is called from an lcd_display_splash_screen(). Account for 24-bit LCDs and files. The bit-per-pixel data structure was a poor-fit with 24-bit, and I didn't even try to support colormapped files on a truecolor display. Great idea because it might save a ton of flash to display an 8bpp image on a 24bpp display.

Quoted 3 lines

3. If there's an overall flash savings, it would be nice to support GIF, PNG, or some other format smaller than a BMP. How complex is the parsing, and would it be a net savings on flash?

I think we should support just one format for two reasons:

1) Supporting just one format keep the code smallest.

2) We have "convert". :)

Quoted 9 lines

4. Account for text overlay on splash screen. There are callbacks for bootup progress, and it's nice to lcd_printf() the status to some rectangle on the screen. Even better if it scrolls or clears nicely.

5. Document and improve the videolfb ATAG. I hardcode my framebuffer to the end of RAM, don't tell linux to use that memory, and pass the info to linux. The display still flickers until you remove the re-initialization, but at least Linux won't move and therefore clobber the contents of the framebuffer.

I dislike this feature. :) IMHO I think it introduces several problems and complications whose can be avoided just defining a boot logo into Linux... however it could be keep into some consideration.

Thanks for your suggestions,

Rodolfo

Hello,

I'm planning to review the splash image support and in order to do that my next steps should be:

1) Remove the logo support.

Currently we have two function for a boot screen: CONFIG_SPLASH_SCREEN and CONFIG_LCD_LOGO. I propose to remove logo support since logos must be statically compiled into u-boot and cannot be changed unless rebuild u-boot. On the other side splash images could be loaded at runtime.

2) Rewrite the lcd_display_bitmap() in order to be more portable across several BPP values.

I'd like to have some suggestions from you before starting to modify the code. :)

FWIIW, I took a screenshot, saved it as a 16 bit BMP, then converted the BMP as a GIF, JPEG, and a PNG. While very unscientific, this says BMP with gzip is a winner for two reasons:
1) It is similar in compression ratios to PNG and GIF
2) We already know how to gunzip and BMP.

Benchmark:
495410 screenshot-16.bmp

25411 screenshot-16.bmp.gz
25875 screenshot-16.PNG
37727 screenshot-16.GIF
148854 screenshot-16.JPG

(Trivia: I did JPEG because it was there. It is generally a poor choice for splash screens because it has artifacts on sharp transitions, which splash screens tend to have.)

I already have a big rewrite of the LCD driver, as I already told you some time ago. Till now I did'nt find the time to post it, sorry. Will do so next week. It supports dynamic display configuration via FDT, which requires substantial modification.

Nevertheless, for true-color display (BPP >= 8) we should use "drivers/cfb_console.c". "common/lcd.c" just supports properly monochrome and 8-bit displays with color table. It would make more sense to spend time for a unified display driver in U-Boot. Unfortunately, that's not a trivial task.

What color format do you want to support?

Quoted 4 lines · Wolfgang Grandegger

I already have a big rewrite of the LCD driver, as I already told you some time ago. Till now I did'nt find the time to post it, sorry. Will do so next week. It supports dynamic display configuration via FDT, which requires substantial modification.

Great! Can we have a preview? :P

Which modifications are you talking about? In the per-CPU framebuffer code?

Quoted 6 lines

Nevertheless, for true-color display (BPP >= 8) we should use "drivers/cfb_console.c". "common/lcd.c" just supports properly monochrome and 8-bit displays with color table. It would make more sense to spend time for a unified display driver in U-Boot. Unfortunately, that's not a trivial task.

I see. Currently I need a splash screen for my custom boards so I have to find a quinck&trick solution! ;)

However I'll do modifications on your new code.

Quoted 1 line · Wolfgang Grandegger

What color format do you want to support?

16 bpp

I already have a big rewrite of the LCD driver, as I already told you some time ago. Till now I did'nt find the time to post it, sorry. Will do so next week. It supports dynamic display configuration via FDT, which requires substantial modification.

Hi Wolfgang,

it would be fine if you consider my 'add splashimage positioning support' patch I sent to the list about two weeks ago. This allows positioning the splashimage somewhere or even aligned through the splashimage variable.

Quoted 4 lines

I already have a big rewrite of the LCD driver, as I already told you some time ago. Till now I did'nt find the time to post it, sorry. Will do so next week. It supports dynamic display configuration via FDT, which requires substantial modification.

Matthias

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Hi Matthias,

Quoted 5 lines · Matthias Fuchs

Hi Wolfgang,
it would be fine if you consider my 'add splashimage positioning support' patch
I sent to the list about two weeks ago. This allows positioning the splashimage somewhere or even aligned through the splashimage variable.

OK. But this patch is for cfb_console.c, which I actually do not use or even touch. I'm dealing with "common/lcd.c", which is different in various respects :-(. Hope you now realized the mess. Nevertheless, from my point of view, the patch is fine and can go up-stream, but I'm not the custodian. Rodolfo, have you looked at it?

Quoted 3 lines · Rodolfo Giometti

Quoted 1 line · Wolfgang Grandegger

What color format do you want to support?

16 bpp

Then use "drivers/cfb_console.c" as it already supports that format. Adapting the interface to pxafb should not be a big deal.

Quoted 6 lines · Wolfgang Grandegger

Quoted 3 lines · Rodolfo Giometti

Quoted 1 line · Wolfgang Grandegger

What color format do you want to support?

16 bpp

Then use "drivers/cfb_console.c" as it already supports that format. Adapting the interface to pxafb should not be a big deal.

In order to adapt pxafb support to "drivers/cfb_console.c" I think I should move cpu/pxa/pxafb.c to drivers/pxafb.c adapting the internal functions to use video_hw_init() and video_set_lut(). Is that right?

Quoted 4 lines · Rodolfo Giometti

Quoted 3 lines · Wolfgang Grandegger

Quoted 2 lines · Rodolfo Giometti

Quoted 1 line · Wolfgang Grandegger

What color format do you want to support?

Quoted 6 lines

Quoted 3 lines

Quoted 1 line

16 bpp

Then use "drivers/cfb_console.c" as it already supports that format. Adapting the interface to pxafb should not be a big deal.

In order to adapt pxafb support to "drivers/cfb_console.c" I think I should move cpu/pxa/pxafb.c to drivers/pxafb.c adapting the internal functions to use video_hw_init() and video_set_lut(). Is that right?

I think so and drivers is also the correct place for pxafb.c.

Quoted 12 lines · Wolfgang Grandegger

Quoted 10 lines · Rodolfo Giometti

Quoted 6 lines · Wolfgang Grandegger

Quoted 3 lines · Rodolfo Giometti

Quoted 1 line · Wolfgang Grandegger

What color format do you want to support?

16 bpp

Then use "drivers/cfb_console.c" as it already supports that format. Adapting the interface to pxafb should not be a big deal.

In order to adapt pxafb support to "drivers/cfb_console.c" I think I should move cpu/pxa/pxafb.c to drivers/pxafb.c adapting the internal functions to use video_hw_init() and video_set_lut(). Is that right?

Quoted 1 line

I think so and drivers is also the correct place for pxafb.c.

Ok, I'll propose a patch ASAP. However, simply moving the file from cpu/pxa/ to drivers/ shouldn't break any code but modifying it in order to support cfb_console.c will do.

What do you suggest in order to do the right steps? Maybe should I remove lcd.c support before doing my modifications?

Quoted 1 line

Ok, I can add a defined() but this is not the right solution IMHO.

OK, why not.

Quoted 2 lines

I wish to remove LCD support at all... are you agree? Any suggestions in order to which steps I should do for better result?

Well, removing LCD support means that you provide a working alternative. My proposal is to re-write a unified display driver for u-boot-v2 and do _not_ waste too much time with the old drivers.

Quoted 12 lines · Rodolfo Giometti

Quoted 11 lines · Wolfgang Grandegger

Quoted 10 lines · Rodolfo Giometti

Quoted 6 lines · Wolfgang Grandegger

Quoted 3 lines · Rodolfo Giometti

Quoted 1 line · Wolfgang Grandegger

What color format do you want to support?

16 bpp

Then use "drivers/cfb_console.c" as it already supports that format. Adapting the interface to pxafb should not be a big deal.

In order to adapt pxafb support to "drivers/cfb_console.c" I think I should move cpu/pxa/pxafb.c to drivers/pxafb.c adapting the internal functions to use video_hw_init() and video_set_lut(). Is that right?

Quoted 7 lines

Quoted 1 line

I think so and drivers is also the correct place for pxafb.c.

Ok, I'll propose a patch ASAP. However, simply moving the file from cpu/pxa/ to drivers/ shouldn't break any code but modifying it in order to support cfb_console.c will do.

What do you suggest in order to do the right steps? Maybe should I remove lcd.c support before doing my modifications?

Just to gain some time and doing some tests I did the modifications in order to support splash screen into cfb_console for PXAFB.

I noticed that I have to disable some code regarding LCD otherwise there are doubled code execution and several incongruences, see here:

   static int bmp_display(ulong addr, int x, int y)
   {
   #if defined(CONFIG_LCD)
           extern int lcd_display_bitmap (ulong, int, int);

           return (lcd_display_bitmap (addr, x, y));
   #elif defined(CONFIG_VIDEO)
           extern int video_display_bitmap (ulong, int, int);
           return (video_display_bitmap (addr, x, y));
   #else
   # error bmp_display() requires CONFIG_LCD or CONFIG_VIDEO
   #endif
   }

This code seems OK but if you doesn't define CONFIG_LCD you cannot get framebuffer memory here (lib_arm/board.c):

   #ifdef CONFIG_LCD
   #       ifndef PAGE_SIZE
   #         define PAGE_SIZE 4096
   #       endif
           /*
            * reserve memory for LCD display (always full pages)
            */
           /* bss_end is defined in the board-specific linker script */
           addr = (_bss_end + (PAGE_SIZE - 1)) & ~(PAGE_SIZE - 1);
           size = lcd_setmem (addr);
           gd->fb_base = addr;
   #endif /* CONFIG_LCD */

Ok, I can add a defined() but this is not the right solution IMHO.

I wish to remove LCD support at all... are you agree? Any suggestions in order to which steps I should do for better result?

Thanks in advance,

Rodolfo