From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Jackson Date: Thu, 29 Jan 2009 10:01:25 +0000 Subject: [U-Boot] [PATCH v3] Add 16bpp BMP support In-Reply-To: <20090128211134.A88C2832E416@gemini.denx.de> References: <497F1732.6050901@mimc.co.uk> <20090128211134.A88C2832E416@gemini.denx.de> Message-ID: <49817E75.7060907@mimc.co.uk> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >> --- >> >> 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 >> + 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