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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 17 Nov 2006 18:40:05 +0000 (GMT)
From:	James Simmons <jsimmons@...radead.org>
To:	Franck Bui-Huu <vagabon.xyz@...il.com>
cc:	Linux Fbdev development list 
	<linux-fbdev-devel@...ts.sourceforge.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>
Subject: Re: [Linux-fbdev-devel] fbmem: is bootup logo broken for monochrome
 LCD ?


> > +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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/