Alternatively, couldn't a blit be inserted somewhere such that a conversion
is done at the point of updating the display (and would this include a
regionlist of areas that have changed to optimise it?). Is there such an
'update point'?
Mathias Agopian
<[EMAIL PROTECTED]
gle.com> To
Sent by: [email protected]
[EMAIL PROTECTED] cc
ooglegroups.com
Subject
[android-porting] Re: Android
02/12/2008 09:14 porting problem - LCD BPP
Please respond to
[EMAIL PROTECTED]
ooglegroups.com
On Mon, Dec 1, 2008 at 11:03 PM, FlyCry <[EMAIL PROTECTED]> wrote:
>
> My lcdc support 2 format of 18bpp framebuffer. One is 18bpp packed.
> Another is a format of 3 byte:
> Red[5:0] 0 0 Green[5:0] 0 0 Blue[5:0] 0 0
> could the second format be configed in android display?
So there are no mode where it has the color components in the higher 6
bits?!
There is a way to configure pixelflinger to be able to render into
arbitrary bit-patterns, however, the format you're describing has
never been tested (obviously). It would also be a huge performance hit
because:
1) we would have to make sure all windows are created in 32-bits (only
mode > 16 bits supported by the software render), which also implies
much higher memory usage and bus pressure
2) the 32-bits surface will have to be converted at runtime and in
software to 18 bits.
To make it work you'd have to add a new pixelformat describing your
framebuffer to pixelflinger, then you would have to make sure the code
that handles the framebuffer (EGLNativeDisplay.cpp) returns that.
You'd have to modify surfaceflinger to always create 32-bits surfaces.
Currently there is no abstraction for all these aspects, so it'll have
to be hacked in.
On top of that, you'll have to replace all the 16-bits assets (because
you wouldnt' get any benefit otherwise).
Performance will likely be bad do to the increased bus pressure,
memory usage and CPU pressure needed for conversion.
I can't believe the framebuffer cannot be configured to 32-bits like this:
xxxxxxxxbbbbbb00gggggg00rrrrrr00
this wouldn't cost anything more in h/w (just more address space, but
who cares?), and it would be a lot more efficient from a software
point of view.
mathias
> Thanks.
>
> On 12月2日, 下午12时42分, Mathias Agopian <[EMAIL PROTECTED]>
wrote:
>> Hi,
>>
>> On Mon, Dec 1, 2008 at 8:22 PM, FlyCry <[EMAIL PROTECTED]> wrote:
>>
>> > My board has an lcd of 18 bpp, but android UI is 16 bpp. So the
>> > display is abnormal when andriod runs. Could android be configed to 18
>> > bpp? And how to do it?
>> > Thanks for anyone attention to this topic.
>>
>> What's the format of your 18bpp framebuffer? (hopefully it's not 18bpp
packed!).
>>
>> Mathias
> >
>
ForwardSourceID:NT000040E6
--~--~---------~--~----~------------~-------~--~----~
unsubscribe: [EMAIL PROTECTED]
website: http://groups.google.com/group/android-porting
-~----------~----~----~----~------~----~------~--~---
