All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodolfo Giometti <giometti@enneenne.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [RFC] Splash image
Date: Wed, 18 Jul 2007 15:58:15 +0200	[thread overview]
Message-ID: <20070718135815.GF4836@enneenne.com> (raw)
In-Reply-To: <f7l58g$fu3$1@sea.gmane.org>

On Wed, Jul 18, 2007 at 09:40:28AM -0400, Joey Oravec wrote:
> "Rodolfo Giometti" <giometti@enneenne.com> wrote in message 
> news:20070718083012.GE4836 at enneenne.com...
> > 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.

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

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

1) Supporting just one format keep the code smallest.

2) We have "convert". :)

> 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

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at gnudd.com
Embedded Systems                     		giometti at linux.it
UNIX programming                     phone:     +39 349 2432127

  reply	other threads:[~2007-07-18 13:58 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-18  8:30 [U-Boot-Users] [RFC] Splash image Rodolfo Giometti
2007-07-18 13:40 ` Joey Oravec
2007-07-18 13:58   ` Rodolfo Giometti [this message]
2007-07-18 14:31     ` Jerry Van Baren
2007-07-18 15:32       ` Rodolfo Giometti
2007-07-18 14:47 ` Wolfgang Grandegger
2007-07-18 15:37   ` Rodolfo Giometti
2007-07-18 16:03     ` Wolfgang Grandegger
2007-07-18 16:01       ` Rodolfo Giometti
2007-07-18 16:17         ` Wolfgang Grandegger
2007-07-19  8:36           ` Rodolfo Giometti
2007-07-19  9:47             ` Wolfgang Grandegger
2007-07-19  9:52               ` Rodolfo Giometti
2007-07-19 14:18                 ` Rodolfo Giometti
2007-07-19 14:41                   ` Wolfgang Grandegger
2007-07-19 14:40                     ` Rodolfo Giometti
2007-07-19  7:09   ` Matthias Fuchs
2007-07-19  8:19     ` Wolfgang Grandegger
2007-07-19  8:33       ` Rodolfo Giometti
     [not found] <008901c7ca10$f1921a40$d4b64ec0$@com>
2007-07-19 20:30 ` Wolfgang Grandegger

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=20070718135815.GF4836@enneenne.com \
    --to=giometti@enneenne.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.