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

Mark Jackson
2009-01-29T10:01:25Z

Wolfgang Denk wrote:
> Dear Mark Jackson,
>
> In message <497F1732.6050901@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 to other platforms should be a simple task !!
>>
>> Signed-off-by: Mark Jackson <mpfj@mimc.co.uk>
>> ---
>>
>> common/lcd.c | 49 +++++++++++++++++++++++++++++++++++++++----------
>> 1 files changed, 39 insertions(+), 10 deletions(-)
>>
>> diff --git a/common/lcd.c b/common/lcd.c
>> index ae79051..16d6f2a 100644
>> --- a/common/lcd.c
>> +++ b/common/lcd.c

<snip>

>> + 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
>
> bmap += (width - padded_line) * 2;
> ?

The "bmap += ..." line is to step forward to the start of the next line of bmp
data, taking into account any padding bytes.

If I read the code correct, padded_line is defined as ...

padded_line = (width&0x3) ? ((width&~0x3)+4) : (width);

... so it will always be >= width. Correct ?

If so, then ...

bmap += (width - padded_line) * 2;

... will be <= 0, and so will actually step bmap back into the data you've
just used, whereas ...

bmap += (padded_line - width) * 2;

... will be >= 0, and will step forward to the start of the next line as required.

Or have I misunderstood the bmp format and the existing code ?

Regards
Mark