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]

Message-ID: <cda58cb80611230653x2951d9d8x41b193f0101f9fdf@mail.gmail.com>
Date:	Thu, 23 Nov 2006 15:53:16 +0100
From:	"Franck Bui-Huu" <vagabon.xyz@...il.com>
To:	"James Simmons" <jsimmons@...radead.org>
Cc:	"Andrew Morton" <akpm@...l.org>,
	"Linux Fbdev development list" 
	<linux-fbdev-devel@...ts.sourceforge.net>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: [Linux-fbdev-devel] fbmem: is bootup logo broken for monochrome LCD ?

On 11/22/06, James Simmons <jsimmons@...radead.org> wrote:
> Replace the below line in my patch I sent
>
> > >                     val |= color << shift;
>
> with
>                         val <<= shift;
>                         val |= color;

I think it can't work since shift is 0 to 31, you'll end up with 'val
<<= 31' which I don't think is what you want.

doing
                         val <<= 1;

make it works but it's still very fragile. Code which deals with
trailing bit seems bogus since new value of 'val' is simply discarded
here.

                /* write trailing bits */
                if (shift) {
                        u32 end_mask = (~(u32)0 << shift);

                        val = FB_READL(dst1);
                        val &= end_mask;
                        FB_WRITEL(val, dst1);
                }

Another thing is that I don't see how very small images (for example
when image->width = 4) will be handled.

> > >                    /* Did the bitshift spill bits to the next long? */
> > >                        if (shift >= 31) {
> > >                                FB_WRITEL(val, dst++);
> > >                                val = (shift == 31) ? 0 :(color >> (32 - shift));
> > >                        }
> > >                        shift += 1;
> > >                        shift &= (32 - 1);
> > >                }
> > >
> > >                [ ...]
>
> Let me know if that works.

I'm wondering if working with 32 bits words really worth... I mean the
code is quite hard to follow because it needs to deal with endianess,
heading bits, trailings bits whereas working with 8 bits would be so
much easier, wouldn't it ? Are writings in video RAM very long ?

-- 
               Franck
-
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/