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

[Mark Jackson <mpfj@mimc.co.uk>]

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