I am doing LCD bring-up also, thought I would chime in. For those of you require 18bit support, are you certain your LCD controller is capable only with 18bit output (ie there are only 6 pins for each of R, G, B), and is indeed reading from packed 18bit in memory? The display controllers I have worked with all support at least some types of 16/24/32 bit layout, and it would be easier to change that setting (a few register writes) than perform surgery on the Android stack.
On Jan 30, 2:11 pm, Dianne Hackborn <[email protected]> wrote: > "red.offset=12,green.offset=6,red.offset=0 with 16 bpp" makes no sense, > unless you are saying in that case it only uses 4 bits for red? > > If you can't actually do RGB565 (which is the only thing that makes sense > in 16 bpp), you will need to run at full 32 bpp RGB888. Those are the only > things Android currently supports. > > That said, I *think* that if you are supporting hardware accelerate > compositing (which you basically need to have good performance at least on > anything above QVGA), then the actual frame buffer may not matter, since it > is your hardware doing the final compositing to it. You need to support the > standard source surface formats anyway (RGB565, RGB888, ARGB888), so if your > hardware can composite those to the screen then surface flinger probably > won't actually care what layout of pixels you have in your 32bpp frame > buffer. > > > > On Wed, Jan 5, 2011 at 7:01 AM, nitin vishnoi <[email protected]> wrote: > > My hardware board with TFT Lcd is supporting only > > red.offset=12,green.offset=6,red.offset=0.with any of the bpp either > > 16,24,32 in the driver level and i am getting linux logo correctly. > > But Android is supporting only RGB565 format so home screen of android i am > > getting with completely distortion of colors. > > So how can i solve this issue. > > And where can i modify so that i can get android display correctly. > > Please help me out with any good idea. > > > On Wed, Dec 29, 2010 at 11:51 AM, Dianne Hackborn > > <[email protected]>wrote: > > >> I have never seen a display that actually has a 18bpp frame buffer. Are > >> you sure that is what you have? Usually when a display is claimed to be > >> 18bpp, it is using a 16bpp frame buffer and wiring the green low bit to the > >> red and blue low bits. > > >> On Wed, Dec 29, 2010 at 7:42 AM, [email protected] < > >> [email protected]> wrote: > > >>> Hi > >>> I am porting android for 18bpp display.But in android(Cupcake)only > >>> 16bpp(RGB565) support is there.Is there any proper way to make it work > >>> for 18bpp display. > > >>> -- > >>> unsubscribe: > >>> [email protected]<android-porting%[email protected]> > >>> website:http://groups.google.com/group/android-porting > > >> -- > >> Dianne Hackborn > >> Android framework engineer > >> [email protected] > > >> Note: please don't send private questions to me, as I don't have time to > >> provide private support, and so won't reply to such e-mails. All such > >> questions should be posted on public forums, where I and others can see and > >> answer them. > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > Note: please don't send private questions to me, as I don't have time to > provide private support, and so won't reply to such e-mails. All such > questions should be posted on public forums, where I and others can see and > answer them. -- unsubscribe: [email protected] website: http://groups.google.com/group/android-porting
