From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Franck Bui-Huu" Subject: Re: fbmem: is bootup logo broken for monochrome LCD ? Date: Tue, 21 Nov 2006 10:45:41 +0100 Message-ID: References: <45535C08.5020607@innova-card.com> Reply-To: linux-fbdev-devel@lists.sourceforge.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1GmSCH-0004jr-6z for linux-fbdev-devel@lists.sourceforge.net; Tue, 21 Nov 2006 01:45:45 -0800 Received: from ug-out-1314.google.com ([66.249.92.170]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1GmSCF-0003u3-Kx for linux-fbdev-devel@lists.sourceforge.net; Tue, 21 Nov 2006 01:45:45 -0800 Received: by ug-out-1314.google.com with SMTP id z38so1409321ugc for ; Tue, 21 Nov 2006 01:45:41 -0800 (PST) In-Reply-To: Content-Disposition: inline List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-fbdev-devel-bounces@lists.sourceforge.net Errors-To: linux-fbdev-devel-bounces@lists.sourceforge.net To: James Simmons Cc: Andrew Morton , Linux Fbdev development list , Linux Kernel Mailing List On 11/20/06, James Simmons wrote: > > > On 11/17/06, James Simmons wrote: > > > > > > Are those actually numbers? If they are the problem isn't byte reversal > > > but bit shifting. > > > > > > 1010100 = 54 > > > 0101010 = 2A > > > > It's not byte reversal, but _bits_ of each bytes have been inversed > > (bit7->bit0, bit6->bit1, bit5->bit2, bit4->bit3, bit3->bit4, ...) > > after calling slow_imageblit(). Is it something expected ? > > Yipes!! Bit reversal. I have never seen that before. Is only the logo > messed up? Slow_imageblit can be called if there is no dword alignment > for the font bitmaps. So the question is do most if not all our fonts > look okay? > No, it's not an only logo issue. Bit reversals happen for all images which are passed to slow_imageblit() including all fonts. Can it be a 'bit_per_pixel = 1' issue ? It seems that this config has not been widely tested. If you look at slow_imageblit() current implementation and for example let's say that at the begining of the function we have: - __LITTLE_ENDIAN is defined - bpp = 1 - fgcolor = 1 - bgcolor = 0 - start_index = 0 The function core can be simplified into: for (i = image->height; i--; ) { shift = val = 0; l = 8; j = image->width; dst = (u32 __iomem *) dst1; s = src; while (j--) { l--; color = (*s & (1 << l)) ? 1 : 0; val |= color << shift; /* Did the bitshift spill bits to the next long? */ if (shift >= null_bits) { FB_WRITEL(val, dst++); val = (shift == null_bits) ? 0 : FB_SHIFT_LOW(color,32 - shift); } shift += 1; shift &= (32 - 1); if (!l) { l = 8; s++; }; } [ ...] Doesn't this bit of code do a bit reversal ? Specially these 2 following lines of code: color = (*s & (1 << l)) ? 1 : 0; val |= color << shift; with 'l' taking values from 7 to 0, and 'shift' taking values from 0 to 31. Thanks Franck ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV