Hi Guys,

Something nobody seems to notice is that the performance of 18bit is total suck! My experiments in benchmarking 18-bit vs broken 16-bit is that 16 is at least 4 times faster and also requires much less bit juggling for putpixel routines and the like...

Steve/theGod: How is that 16-bit mode fix going? :) :) I would offer my help but I'm not sure where to start!

Xris.

thaGod wrote:
These are the exact color swaps I experienced with a color bar pattern and
the old misaligned pxafb.c driver. Per Steve's suggestion that the latest
version is up to date and correct you should be sure you're using the latest
svn revision. If that doesn't work then I would be happy to send you my
version of pxafb.c and pxaregs.h so that you may compare differences or use
them or whatever you choose.

I did my testing using directfb-1.1 (which is pretty easy to get compiled
and a very good test foundation) and eventually won.

Erick


Justin Rajewski wrote:
  
I did find out that for each Pixel you need three app->screen_ptr[i] =
0xFF; here is a picece of the modified  code that cycles through the
colors. 
static FBTErr fbt_clear( App *app ) {
  FBTErr err = FBT_E_NOERR;
  unsigned int i, size,col,r,g,b;

  do {
    if( NULL == app ) {
      err = FBT_E_NULL;
      break;
    }
/*
printf ("Enter the three bytes:");
scanf("%x %x %x",&r,&g,&b);
*/
r=0;
g=0;
b=0;
while (1){
    for( i = 0; i < app->size; i+=3 ) {
	app->screen_ptr[i] = b;
	app->screen_ptr[i+1] = g;
	app->screen_ptr[i+2] = r ;
++b;
if (b>0x3F){
b=0;
g++;
}
if (g>0x3F){
g=0;
r++;
}
if (r>0x3F)break;
}
if (r>0x1F)break;
usleep (1000000);
}
  } while( 0 );

  return( err );
  
}
I still am not sure on the bit arrangement as send 0x0f 0x0f 0x0f should
make gray it makes yellow. The code above assumes that it is like XXBBBBBB
XXGGGGGG XXRRRRRR.
Thanks,
Justin

Justin Rajewski wrote:
    
Steve,
In the program on
http://hbmobile.org/wiki/index.php?title=FBDirectOnConsoleLCD there is
the line 
app->screen_ptr[i] = 0xFF; 
Does this mean I need to do this three times per pixel? For example like
xxxxxxRR RRRRGGGG GGBBBBBB? 
Also after about 5 minutes the LCD turns off, the back light is still on
but the display stops getting updated. Is this normal?
Thanks,
Justin

Steve Sakoman wrote:
      
Eric,

As far as I can tell, the current source base is correct for RGB18.

These 18 bits of color info are aligned on 24 bit boundaries (ie with
6 wasted bits per pixel).  Not optimal, but that's what it is.

I'm not sure why you say it doesn't work.  There are certainly issues
with a lack of support for RGB18 in the open source world, but that is
another problem.

Steve

On Jan 13, 2008 12:32 PM, thaGod <thagod@gmail.com> wrote:
        
Well the good news is that all the hardware is right as far as the LCD
bits
are concerned. It is 18bit color. It is a software issue. You are going
to
have to implement those changes in the LDD_16 and LDD_17 thread
somehow..
although I haven't run the problem down again since Craig put together
patches for the source. It appears as though the problem still exists?

The other color bits are supposed to be aranged in 666 format, but it
doesn't work because they are not aligned properly in pxafb.c. In my
workaround I returned it to 565 format and threw away the least
significant
bits of red and blue.

If you fix it this way be sure you leave your framebuffer in 18bpp mode
even
though there are only 16 bits being used. It's an ugly fix, but it
works for
the time being.

Erick



Justin Rajewski wrote:
          
One last question, is there some way to wait for the vblank, so the
changes are smooth?

Justin Rajewski wrote:
            
My LCD only showed green and blue. The red was very low and you
              
could
          
almost not see it. I would try updating to the newest SVN. I used
              
the
          
ConsoleLCD-Vx so I did not have to wire anything.


Justin Rajewski wrote:
              
One more thing, is not the color 18bpp? When I use 0xFF it is white
                
and
          
0x00 is black, that makes 8bpp. Also how are the color bits
                
arranged?
          
Like BBBGGGGRRR?
Thanks,
Justin

Demetris Zavorotnichenko wrote:
                
Have I understood this post correctly ?

I have a problem with my LCD as well.

My problem is that I have all the connections for the LCD correct
                  
but
          
when I
want to view something then the Green and Blue are inverted so I
                  
see
          
green
where is blue and blue where is green.

Was this a problem and now is fixed ?

-----Original Message-----
From: gumstix-users-bounces@lists.sourceforge.net
[mailto:gumstix-users-bounces@lists.sourceforge.net] On Behalf Of
Justin
Rajewski
Sent: Sunday, January 13, 2008 8:33 PM
To: gumstix-users@lists.sourceforge.net
Subject: Re: [Gumstix-users] LCD only blue and green?


I updated the SVN to the newest and now it works great.
Thanks,
Justin

thaGod wrote:
                  
I'm not exactly sure where the code revisions were introduced,
                    
but the
          
pxafb.c and pxaregs.h files appear to still be wrong on your
                    
setup. I
          
think to a certain extent these problems have been fixed in the
                    
latest
          
code revisions... most likely the open embedded images that Steve
                    
has
          
been
working on. I can say for sure though that there is an older
                    
thread on
          
this mailing list regarding LDD_16 and LDD_17 missing from
                    
pxaregs.h.
          
There is instruction documented there on how to realign the bits
                    
to
          
display colors properly.

The jist of it is as follows. LDD_16 and LDD_17 used to be
                    
missing
          
from
pxaregs.h. These are the two most significant red bits. The bit
alignment
shift occurs partially as a result of this, and partially because
                    
the
          
pxafb.c driver was written wrong. There are instructions for
re-offsetting
the bits in that thread. I believe the pxaregs.h patchwork is
                    
fixed
          
already.. you might check anyways. You might also try updating to
                    
the
          
latest SVN if you haven't already. Another option is to try the
                    
open
          
embedded images that Steve has prepared.

Search for and read through those threads and hit me back... I'll
                    
be
          
happy
to help if you have any problems figuring it out.

Erick


Justin Rajewski wrote:
                    
Also I tried the LCD demo code on the wiki. I get segmentation
                      
fault
          
but
it does make a box on the LCD. Does anyone have a code that will
                      
show
          
red and works with the LCD gumstix sells?

Thanks,
Justin



                      
-------------------------------------------------------------------------
          
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.

                      
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
          
_______________________________________________
gumstix-users mailing list
gumstix-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gumstix-users


                      
                    
--
View this message in context:

                  
http://www.nabble.com/LCD-only-blue-and-green--tp14779923p14789259.html
          
Sent from the Gumstix mailing list archive at Nabble.com.



                  
-------------------------------------------------------------------------
          
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.

                  
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
          
_______________________________________________
gumstix-users mailing list
gumstix-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gumstix-users




                  
-------------------------------------------------------------------------
          
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.

                  
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
          
_______________________________________________
gumstix-users mailing list
gumstix-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gumstix-users


                  
                
              
            
--
View this message in context:
http://www.nabble.com/LCD-only-blue-and-green--tp14779923p14790640.html

Sent from the Gumstix mailing list archive at Nabble.com.


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
gumstix-users mailing list
gumstix-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gumstix-users

          
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
gumstix-users mailing list
gumstix-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gumstix-users