Subject: RE: Framebuffer driver on Assabet

From: Jeff Sutherland <[email-masked]>
Date: Tue, 9 May 2000 16:22:50 -0400

Ok, folks, I think I'm getting a handle on this.  The basic problem it seems
is that I have a display (and its controller implemented in a CPLD) thinking
it's a 16bpp device (which it is) looking at a frame buffer which is
configured with a 512 byte palette and loaded with an 8bpp image.  The
display *really* wants to see a frame buffer with no palette at the front
loaded with a 16bpp image, I believe.  Looking closely at the image on the
display (and after analyzing debug output from sa1100fb.c) it's apparent
that this is what's going on.  For most of the first scan line there's
random data (the palette) followed by about 1/2 screen of a double image,
then the rest is whatever DCAR1 is finding out beyond the end of the loaded
image until the frame pulse hits.  If "16" is not valid for
current_par.max_bpp, what's the magic fix?

//Jeff

unsubscribe: body of `unsubscribe linux-arm-kernel' to [email-masked]

---

From: Nicolas Pitre <[email-masked]>
Date: Tue, 9 May 2000 16:37:07 -0400 (EDT)

On Tue, 9 May 2000, Jeff Sutherland wrote:

> loaded with a 16bpp image, I believe.

However if you configure the LCD controller for 8 bpp which the code
currently does, it should work anyway.  It apparently works for some
people at least.

Of course a proper 16 bpp mode support would be the best solution...

Nicolas