Subject:
Re: Re(2): [nanogui] 16bit color depth in microwindows
From:
"Greg Haerr" ####@####.####
Date:
6 Nov 2001 15:25:10 -0000
Message-Id: <029001c166d7$05bda140$3aba46a6@xmission.com>
: 1) Almost all of the Epson "embedded" LCD controllers have
: 16 bit CPU data interfaces. And, MicroWindows (as well
: as most other LINUX software) expects to do optimized
: 32-bit data transfers to the video memory. Now, this is
: not a problem if your CPU (or it's external support chip set)
: supports "dynamic bus sizing".......which takes a 32-bit
: "write cycle" and (in hardware) automatically breaks it up
: into two 16-bit write cycles. However, the StrongARM
: (as well as many other embedded CPUs) do not support
: this. As a result, when running in 16 bit / pixel mode, the
: software tries to write two pixels at a time. Only ONE
: gets to the video memory......the other 16 bits of data goes
: to the "bit bucket", and leaves a black spot on the screen.
Actually, the current 16bpp fb driver fblin16.c only writes
16 bits at a time. However, this is interesting information
for some of the optimized drivers that I've been working on,
which draw 32 bits at a time for speed.
: The solution is to look at all of the drawing routines, and
: "un-optimize" them to do two 16-bit writes in software
: wherever 32-bit writes are attempted. The amount of
: work to do this is not trivial, but we have most of this
: done already. If Greg is interested, we can submit our
: "patches" back to him so MicroWindows can support
: other people's 16-bit video projects as well.
I am definitely interested, please send me your unoptimized
drivers, I will include them in the project.
: 2) The Epson LCD controllers (the simpler ones anyways)
: do not have internal pallettes. When running in 565
: mode, you have fixed bit assignments to each bit
: in a word of video memory.
: This cannot be changed, so "pallette support" and
: color mapping has to be handled externally in software.
Perhaps you should try running the LCD controller using
the Microwindows TRUECOLOR555 format, rather
than 565.
:
: Now, we have tried all of the MicroWindows demos.
: Everything runs just fine .... even the "Alpha Blending" demo
: (the one with the red car that has text overlays over it) ... these
: demos all look just perfect on the Epson system. And those
: are a mix of 8 bit/pixel to 24 bit/pixel source files. But, none
: of the demos are in 16 bit TRUECOLOR565 mode.....
What do you mean? The demos either specify RGB, which
is required for all color specifications in source code, or
they use converted .bmp files. I just recently added support
for non-8bpp .bmp files in the CVS Microwindows. Do you
suppose the problem is lack of decoder for 24bpp .bmp files?
: Now, these pictures look just fine when we try to
: display them on a desktop LINUX PC, running under x11.c
: MicroWindows. But, on a StrongARM under the fb.c LCD "framebuffer
: driver", the same image is visible, but the colors are all out of whack.
: There clearly is a pallette / color mapping problem here, but we
: have no idea where.
I think the GIF decoder only decodes to 8bpp w/palette.
Perhaps theres an error in the devdraw.c::GdDrawImage().
Check what bpp X11 is running at. If it's running 16bpp,
then the problem is likely that the epson is running at 15bpp.
Regards,
Greg
:
: Now, simple GWES graphics calls under Windows CE (draw line,
: draw text, fill area) all work just fine. There must be some sort of
: "display .GIF" function that is not handling the pallettes correctly ...
: or at least that is our assumption. Of course, we don't have source
: code for ANYTHING under WinCE. What a pain...
:
: Has anyone seen this before? Any pointers?
:
:
: Bill Mohat
: Telos Systems
:
:
:
:
: ---------------------------------------------------------------------
: To unsubscribe, e-mail: ####@####.####
: For additional commands, e-mail: ####@####.####
:
