"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

Reply via email to