Subject:
Re: Re(2): Re(2): [nanogui] 16bit color depth in microwindows
From:
"Greg Haerr" ####@####.####
Date:
6 Nov 2001 15:54:30 -0000
Message-Id: <02c301c166db$1d21a620$3aba46a6@xmission.com>
: 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.
Hmmm... Sounds like a bug in the GdDrawImage code.
Except that this worked OK on the X11 desktop. What
bpp is X11 running at?
This may be a bug in one of the 565 conversion macros
I have defined in src/include/device.h. Please compare the
version you are running with the latest version in CVS.
I had some errors in earlier versions and this could definitely
be the problem.
: 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?
If the 16bpp conversion macros are broken, and your X11 server
isn't running 16bpp, then a broken macro is used to convert the
palette RGB values on the LCD, and a different macro is used
on the X11 desktop.
: 16 bit source files don't work at all....
Yes, known limitation: GdDrawImage doesn't support
16bpp MWIMAGEHDRs yet, this is a straightfwd
enhancement.
: 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.
Yes, please send the patches, I'm interested to see where else
Microwindows has to be modified in order to work with this
HW limitation.
Regards,
Greg
:
: 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: ####@####.####
: >:
: >
:
:
