> > +static inline void slow_imageblit(const struct fb_image *image,
> > + struct fb_info *p, u8 __iomem *dst,
> > + u32 start_index, u32 pitch_index)
>
> I still have my problem there: for example if image data are
> 0, 0, 0x54, 0, ...
>
> then slow_imageblit() will write into the frame buffer, the following bytes:
> 0, 0, 0x2a, 0, ...
>
> instead of the initial ones:
> 0, 0, 0x54, 0, ...
>
> Bits of each bytes are reversed. I already tried to explain my
> problem, please look at
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=116315548626875&w=2
Are those actually numbers? If they are the problem isn't byte reversal
but bit shifting.
1010100 = 54
0101010 = 2A
> > + if (fb_logo.depth == 1) {
> > + if (info->fix.visual == FB_VISUAL_MONO01) {
> > + u32 fg = image.fg_color;
> > +
> > + image.fg_color = image.bg_color;
> > + image.bg_color = fg;
>
> I had to fix this part to make the bootup logo worked. image.fg_color
> is not uninitialised at this point. I had to change this part as
> follow:
>
> if (fb_logo.depth == 1) {
> image.fg_color = (info->fix.visual == FB_VISUAL_MONO01) ? 1:
> 0;
> image.bg_color = !image.fg_color;
> }
>
> Otherwise this part of your patch (the one which fix the logo display)
> seems ok for my naive look. It would be nice if this part could be
> sent in a single patch to Andrew. I already tried to fix it but your
> patch looks better.
Your right about the colors not being set for mono logo. Your above fix is
not correct but it needs to be fixed. I really don't understand why
fbmem.c has its own routines to handle the logo for the color map. I can
set creating a fbcmap and calling fb_set_cmap instead. That will be a
separte patch.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
