Subject:
Re: [nanogui] colormap
From:
"Greg Haerr" ####@####.####
Date:
22 Dec 2005 02:52:34 +0000
Message-Id: <009b01c606a2$a8db70e0$6401a8c0@winXP>
: Things are a bit more complicated that one might think, but I'll make the
necessary changes.
:
: However, I need some enlightment with regards to the way nanogui handle
its colors.
: With the ARM9 cpu I'm using, for 16Bpp, no palette is used, it writes
directly to the framebuffer. So it looks like I'll have to set this direct
access first then swap the 'r' and 'b' bits.
Normally 16bpp is no palette, direct framebuffer, so there's nothing really
unique about your setup. The lower level drivers will always write 16 bits
of color format to the framebuffer, they don't care about the color word
contents, so there's no change there. The only change is that you will need
to change the COLORTOPIXELVAL macros as I discused last time
so that the r and b bits go to the right place, and I think you'll be
running.
(You will have to change PIXELTOCOLORVAL macros also, and
possibly the lower level PIXEL888RED etc macros also, but they're
all in one place, and quite easy to swap, since the bit positions aren't
changing, just the color name)
: Am I missing anything? It appears that the visual (scr_fb.c) should be
FB_VISUAL_DIRECTCOLOR instead of TRUECOLOR. Could someone laborate on this?
No need to start changing all that, its just there to try to find out what
the kernel framebuffer driver is saying the hardware format is. We
don't make any distinction between DIRECT and TRUE colors when
running 16bpp. The only reason you'd need to change this code is if
you're kernel driver isn't reporting a valid selection now.
Hope this helps.
Regards,
Greg
: Thanks,
: --ER
:
:
: > -----Original Message-----
: > From: Greg Haerr ####@####.####
: > Sent: Tuesday, December 20, 2005 4:29 PM
: > To: ####@####.#### ####@####.####
: > Subject: Re: [nanogui] colormap
: >
: > : I believe I've found the source. The byte ordering for the arm lcdc
: > driver
: > (linux 2.6.12) is set to BGR and nanoX is assuming RGB. The question is,
: > Is
: > their an easy switch in the nanoX source? I've examine the device.h file
: > and
: > it appears that I'll have to redefine the conversions? Is their a
simpler
: > way I might be missing?
: >
: > I thought redefining macros would be simple :)
: > It should be as simple as changing the positions of 'r' and 'b'
: > in the macro definition, I think.
: >
: > Yes, change the macros to switch the RGB values that your
: > framebuffer requires. When you get it working, send me
: > a patch, and I'll add it to CVS device.h.
: >
: > Regards,
: >
: > Greg
: >
: >
: > ---------------------------------------------------------------------
: > To unsubscribe, e-mail: ####@####.####
: > For additional commands, e-mail: ####@####.####
:
:
:
: _______________________________________________
: Join Excite! - http://www.excite.com
: The most personalized portal on the Web!
:
:
:
: ---------------------------------------------------------------------
: To unsubscribe, e-mail: ####@####.####
: For additional commands, e-mail: ####@####.####
:
:
