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