Re: [Linux-fbdev-devel] fbmem: is bootup logo broken for monochrome LCD ?

From: Franck Bui-Huu
Date: Tue Nov 21 2006 - 04:46:15 EST


On 11/20/06, James Simmons <jsimmons@xxxxxxxxxxxxx> wrote:

> On 11/17/06, James Simmons <jsimmons@xxxxxxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/