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 AVR32 board, but >> extending >> this to other platforms should be a simple task !! >> >> Signed-off-by: Mark Jackson <m...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot