This patch adds 16bpp BMP support to the common lcd code.
Use CONFIG_BMP_16BPP and set LCD_BPP to LCD_COLOR16 to enable the code.
At the moment it's only been tested on the MIMC200 AVR32 board, but extending
this to other platforms should be a simple task !!
Signed-off-by: Mark Jackson
---
Mark Jackson wrote:
> Haavard Skinnemoen wrote:
> > Mark Jackson wrote:
> >>> 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
Dear Mark Jackson,
In message <497f1732.6050...@mimc.co.uk> you wrote:
> This patch adds 16bpp BMP support to the common lcd code.
>
> Use CONFIG_BMP_16BPP and set LCD_BPP to LCD_COLOR16 to enable the code.
>
> At the moment it's only been tested on the MIMC200 AVR32 board, but extending
> this
Wolfgang Denk wrote:
> Dear Mark Jackson,
>
> In message <497f1732.6050...@mimc.co.uk> you wrote:
>> This patch adds 16bpp BMP support to the common lcd code.
>>
>> Use CONFIG_BMP_16BPP and set LCD_BPP to LCD_COLOR16 to enable the code.
>>
>> At the moment it's only been tested on the MIMC200 AVR3
Dear Mark Jackson,
In message <49817e75.7060...@mimc.co.uk> you wrote:
> >> + bmap += (padded_line - width) * 2;
> >> + fb -= (width * 2 + lcd_line_length);
> >
> > Is it intentional that you reverse padded_line and width here, i.e.
> > you are sure it's not
>
Wolfgang Denk wrote:
> Dear Mark Jackson,
>
> In message <49817e75.7060...@mimc.co.uk> you wrote:
>>
>> Or have I misunderstood the bmp format and the existing code ?
>
> I don't know - I'm just asking because the 16 bpp case is different
> from the 1 and 8 bpp cases where the operands are swa
On Tue, 27 Jan 2009, Mark Jackson wrote:
> This patch adds 16bpp BMP support to the common lcd code.
>
> Use CONFIG_BMP_16BPP and set LCD_BPP to LCD_COLOR16 to enable the code.
>
> At the moment it's only been tested on the MIMC200 AVR32 board, but extending
> this to other platforms should be
Dear Guennadi Liakhovetski,
In message 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
On Fri, 30 Jan 2009, Wolfgang Denk wrote:
> > 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
Wolfgang Denk wrote:
> Dear Guennadi Liakhovetski,
>
> In message 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 byte
Mark Jackson wrote:
> > 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 !!
Haavard Skinnemoen wrote:
> Mark Jackson wrote:
>>> 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 differe
12 matches
Mail list logo
