nanogui: Thread: 16bit color depth in microwindows

   I am trying to get the MicroWindows Framebuffer to handle
16 bits / pixel.  (Specifically, TRUECOLOR565).  The pallette
translation works fine on X11 on my host PC-based system.
However, the same image on our embedded system's LCD
display (framebuffer) shows really screwed up colors.

   Does fb.c not handle TRUECOLOR565 correctly?  If so, what
must be done to fix this?

Bill Mohat
Telos Systems

*******************************************************************************8

I haven't had a problem with 565 to date, but there is always a first time.

A little background would be useful:

Is the LCD black and white or color?
What processor are you running on (ie, could it be an endianism problem)
What chipset are you using (does it support 565 in the kernel framebuffer)

Jordan

On Monday 29 October 2001 14:51, William Mohat mentioned:
>    I am trying to get the MicroWindows Framebuffer to handle
> 16 bits / pixel.  (Specifically, TRUECOLOR565).  The pallette
> translation works fine on X11 on my host PC-based system.
> However, the same image on our embedded system's LCD
> display (framebuffer) shows really screwed up colors.
>
>    Does fb.c not handle TRUECOLOR565 correctly?  If so, what
> must be done to fix this?
>
> Bill Mohat
> Telos Systems
>
> ***************************************************************************
>****8
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

:    I am trying to get the MicroWindows Framebuffer to handle
: 16 bits / pixel.  (Specifically, TRUECOLOR565).  The pallette
: translation works fine on X11 on my host PC-based system.
: However, the same image on our embedded system's LCD
: display (framebuffer) shows really screwed up colors.
: 
:    Does fb.c not handle TRUECOLOR565 correctly?  If so, what
: must be done to fix this?

Yes, TRUECOLOR565 is definitely handled correctly.  Your problem is
likely either:

1) The device is really running TRUECOLOR555 (15bpp) rather than 565.

2) The device needs some strange palette values set up in order for
the 5,6,5 to display properly.  Check on the ioctl_setpalette function
(and others nearby) in the drivers/scr_fb.c file.

This same thing happened to me for about a year until I finally
figured out that my home ATI card ran 555 rather than 565.

Greg

: What processor are you running on (ie, could it be an endianism problem)

Jordan brings out a good point, in that some LCD devices actually
run byte-swapped differently from the processor WORD storage,
for speed reasons.

Regards,

Greg

Good Point.  Also, the frame buffer drivers for some processors require you
to jump through hoops to get it to run in 16bit mode.  As an example the
drivers/video/sa1100fb.c driver for the Intel StrongArm seems to have
different settings for every different motherboard.  Depending on the kernel
version, is may be hard to figure out the correct settings for your
processor/board.

Steve

-----Original Message-----
From: Greg Haerr ####@####.####
Sent: Monday, October 29, 2001 3:22 PM
To: ####@####.#### William Mohat; ####@####.####
Subject: Re: [nanogui] 16bit color depth in microwindows



: What processor are you running on (ie, could it be an endianism problem)

Jordan brings out a good point, in that some LCD devices actually
run byte-swapped differently from the processor WORD storage,
for speed reasons.

Regards,

Greg


---------------------------------------------------------------------
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.####

   Some detail on the 16 bit / pixel problem  (TRUECOLOR565):

       We are using a StrongARM processor, with EXTERNAL Epson
LCD controllers.  Here's why:  

         The LCD controller inside the StrongARM
takes up a lot of the CPU's memory bandwidth, and it tends
to "break up"  the video display if any peripheral injects any "wait
states".  The internal LCD controllers are also not fast enough for
TFT panels larger than about 1/2 VGA in size.   Going with 
an external LCD controller solves the "video breakup" problems
(i.e. flicker, speckles and jitter in the display), and also lets
your CPU run about 30% faster.....

    The DOWNSIDE of the external Epson LCD controllers is as 
follows:

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.

      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 would 
        have thought the Epson software people would have 
         been behind this effort, but they aren't.)

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.

   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.....

    Our problem comes in when we are trying to run some software
that was originally intended for Windows CE.  We know the original
software authors did .GIF and / or .BMP images, and used some 
sort of WinCE function to get them painted on WinCE's LCD 
screens.  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.    

    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

Jordan / list:

    We have some software people in Latvia that are trying to help with
this TRUECOLOR 565 problem.   They have been able to get some images
to work, but with some real contortions.   Here is their description of 
what they have to do:


                  " I am doing what I found in Wicrowindows examples. 
                  Unfortunatelly they  haven't implemented *.rc (resource) 
                  files in Microwindows as I know them in Windows.
Therefore
                  to display some image on screen I found folllowing
                  way. (In Windows, and also here all pictures are
originally 
                  stored as .bmp files):
	
	                  convbmp picture.bmp

                  That generates picture.c file. If bmp file is 256 color
bitmap 
                  (as ones that I used) you can see pallete definition in
this 
                  generated .c file. If you use 24bit bitmap as source,
there 
                  are no pallete definition, each pixel is given by RGB
values 
                  (I guess). I haven't tried how 24bit bitmaps looks on
StrongARM, 
                  when converted and displayed with DrawDIB.

                  Then by using special Microwindows function (there are
no 
                  such equivalent in MS API)
	
                              DrawDIB(hdc, 0, 0, &image_picture);

                  I put bitmap on the screen. That was the only way I
found how 
                  to get bmp on screen. If you know of some different,
more 
                  efficient way to do this, let me know.


     The folks in Latvia report that this makes the code very non-portable
between WInCE and LINUX/Microwindows.   Does anyone have any
experience with this?   Is there a better way?


Bill Mohat
Telos Systems












####@####.#### writes:
>I haven't had a problem with 565 to date, but there is always a first
>time.
>
>A little background would be useful:
>
>Is the LCD black and white or color?
>What processor are you running on (ie, could it be an endianism problem)
>What chipset are you using (does it support 565 in the kernel framebuffer)
>
>Jordan
>
>On Monday 29 October 2001 14:51, William Mohat mentioned:
>>    I am trying to get the MicroWindows Framebuffer to handle
>> 16 bits / pixel.  (Specifically, TRUECOLOR565).  The pallette
>> translation works fine on X11 on my host PC-based system.
>> However, the same image on our embedded system's LCD
>> display (framebuffer) shows really screwed up colors.
>>
>>    Does fb.c not handle TRUECOLOR565 correctly?  If so, what
>> must be done to fix this?
>>
>> Bill Mohat
>> Telos Systems
>>
>>
>***************************************************************************
>>****8
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ####@####.####
>> For additional commands, e-mail: ####@####.####

So, basically you are saying that we need to be able to support 24 bit 
bitmaps (those without a palette) in Microwindows?  That shouldn't be too  
hard to accomplish.  Of course, its not always trivial to convert between 
different depths, but we have some existing code that shows the way (the XPM 
code handles conversion from the internal 24 bit mode).  

Also so if there are some special API calls in Windows CE that we have not 
yet been implemented in Microwindows, I don't see any reason why we shouldn't 
try to flesh some of these out.    

Jordan

On Tuesday 30 October 2001 06:42, William Mohat mentioned:
> Jordan / list:
>
>     We have some software people in Latvia that are trying to help with
> this TRUECOLOR 565 problem.   They have been able to get some images
> to work, but with some real contortions.   Here is their description of
> what they have to do:
>
>
>                   " I am doing what I found in Wicrowindows examples.
>                   Unfortunatelly they  haven't implemented *.rc (resource)
>                   files in Microwindows as I know them in Windows.
> Therefore
>                   to display some image on screen I found folllowing
>                   way. (In Windows, and also here all pictures are
> originally
>                   stored as .bmp files):
>
> 	                  convbmp picture.bmp
>
>                   That generates picture.c file. If bmp file is 256 color
> bitmap
>                   (as ones that I used) you can see pallete definition in
> this
>                   generated .c file. If you use 24bit bitmap as source,
> there
>                   are no pallete definition, each pixel is given by RGB
> values
>                   (I guess). I haven't tried how 24bit bitmaps looks on
> StrongARM,
>                   when converted and displayed with DrawDIB.
>
>                   Then by using special Microwindows function (there are
> no
>                   such equivalent in MS API)
>
>                               DrawDIB(hdc, 0, 0, &image_picture);
>
>                   I put bitmap on the screen. That was the only way I
> found how
>                   to get bmp on screen. If you know of some different,
> more
>                   efficient way to do this, let me know.
>
>
>      The folks in Latvia report that this makes the code very non-portable
> between WInCE and LINUX/Microwindows.   Does anyone have any
> experience with this?   Is there a better way?
>
>
> Bill Mohat
> Telos Systems
>
> ####@####.#### writes:
> >I haven't had a problem with 565 to date, but there is always a first
> >time.
> >
> >A little background would be useful:
> >
> >Is the LCD black and white or color?
> >What processor are you running on (ie, could it be an endianism problem)
> >What chipset are you using (does it support 565 in the kernel framebuffer)
> >
> >Jordan
> >
> >On Monday 29 October 2001 14:51, William Mohat mentioned:
> >>    I am trying to get the MicroWindows Framebuffer to handle
> >> 16 bits / pixel.  (Specifically, TRUECOLOR565).  The pallette
> >> translation works fine on X11 on my host PC-based system.
> >> However, the same image on our embedded system's LCD
> >> display (framebuffer) shows really screwed up colors.
> >>
> >>    Does fb.c not handle TRUECOLOR565 correctly?  If so, what
> >> must be done to fix this?
> >>
> >> Bill Mohat
> >> Telos Systems
> >
> >**************************************************************************
> >*
> >
> >>****8
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: ####@####.####
> >> For additional commands, e-mail: ####@####.####
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

:      The folks in Latvia report that this makes the code very non-portable
: between WInCE and LINUX/Microwindows.   Does anyone have any
: experience with this?   Is there a better way?

Yes, DrawDIB() is non-standard.  Since, as they mentioned, 
I haven't got around to getting the .rc files and LoadBMP()
functions implemented, the best bet would be to wrap the
DrawDIB() function with a win32-compatible function like
SetDIBits or SetDIBitsToDevice...  This was initially
more trouble than it's worth, since the MWIMAGEHDR
structure isn't directly compatible with the MS DIB
structure since Microwindows handles more than one API.

Regards,

Greg

: 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: ####@####.####
: