Subject:
Re(2): Re(2): [nanogui] 16bit color depth in microwindows
From:
"William Mohat" ####@####.####
Date:
6 Nov 2001 15:44:40 -0000
Message-Id: <fc.000f6801002ad25c3b9aca009dbc37b3.2ad2c1@telos-systems.com>
Greg:
We are running the Epson controller with a fixed 5-6-5 mapping,
which matches the Truecolor565 format. The software people
were trying to output .BMP images to the frame buffer, using
DrawDIB(). If their source image was 8 bits/pixel (with a pallette
mapping in the file) then the draw would fail. But, if their
source image was 24 bits/pixel, (fixed 8-8-8 mapping) then
everything worked fine.
We have been able to take our original 8 bit/pixel images into
PhotoShop and convert them to 24-bit images. Then, we call
DrawDIB() and MicroWindows displays the images just fine.
But, the source files now take up a lot more space....
Why doesn't DrawDIB handle our 8 bit/pixel images? Are
PC-style 8 bit/pixel images NOT considered "device independent
bitmaps", even if their file extension is .BMP? And why then
do 24bit/pixel images display correctly? Because it's "flat" 8-8-8?
16 bit source files don't work at all....
------
Another topic: 32-bit writes to EPSON controllers (1354, 1355,
etc.) lose every other pixel. We found a few places in
several drawing routines that attempt this. Not just in MicroWindows,
but also in LINUX as well. (The LINUX "console driver" does this all
the time, the "screen saver" does it, etc). C/C++ functions like
memcpy() also are 32-bit, so we had to do our own 16-bit "copy"
operations to directly read and write from the frame buffer. And,
we had to patch every other instance when other people did 32-bit
writes.
I'll have Jim (the software guru here) send you his patches. Other
people with 16-bit CPUs (that DON'T support static or dynamic bus
sizing) might benefit from this. Folks with CPUs that support dynamic
bus sizing (or motherboard chip sets that add this functionality) ... or
folks that use CPUs with static bus sizing (ColdFire, for exmple) would
never notice this effect, since the 32-bit writes are chopped into two
16-bit writes in hardware.
Bill
####@####.#### writes:
>: 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: ####@####.####
>:
>
