Yes, red and blue.
Thanks!
On 12月3日, 下午4时20分, Mathias Agopian <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 2, 2008 at 11:45 PM, FlyCry <[EMAIL PROTECTED]> wrote:
>
> > Thanks for your helpful replies.
> > Acctually, my lcdc support 24-bits packed framebuffer to 18-bits
> > output to suit the 18bpp lcd. The framebuffer format is
> > rrrrrr00gggggg00bbbbbb00, packed.
> > I configed pixelflinger as RGB888. That could compatible to the 24-
> > bits packed framebuffer. But I found the red and the green exchanged
> > their place. Is android's default color space BGR but not RGB? The
> > hardware can't swap red and green. Is there anything I can do to make
> > android swap red and green.
>
> you mean red and blue, right?
>
> SurfaceFlinger should be using RGB (a byte of red followed by a byte
> of green, followed by a byte of blue). Unless there is a bug in
> pixelflinger, that's what it should do. I will check tomorrow if this
> is working properly (I don't think 24-bits mode have ever been used
> before).
>
> Mathias
>
>
>
> > Thanks a lot.
>
> > On 12月2日, 下午6时39分, Phil HUXLEY <[EMAIL PROTECTED]> wrote:
> >> Perhaps I wasn't being clear enough. Some LCD panels do have 18 bits per
> >> pixel, but use some (2 or 3) of those bits for other things (can't remember
> >> what), so the actual colour resolution is 16 bits or less.
>
> >> All I was suggesting was stay in a traditional 565 domain until the final
> >> buffer swap to the screen (i.e. don't change any of the rendering side -
> >> not even the configs), but do as efficient a conversion as possible on the
> >> final swap - potentially easy to do if that final swap can be singled out.
>
> >> Mathias Agopian
> >> <[EMAIL PROTECTED]
> >> gle.com> To
> >> Sent by: android-porting@googlegroups.com
> >> [EMAIL PROTECTED] cc
> >> ooglegroups.com
> >> Subject
> >> [android-porting] Re: Android
> >> 02/12/2008 10:09 porting problem - LCD BPP
>
> >> Please respond to
> >> [EMAIL PROTECTED]
> >> ooglegroups.com
>
> >> On Tue, Dec 2, 2008 at 1:52 AM, Phil HUXLEY <[EMAIL PROTECTED]> wrote:
> >> > I was thinking that the system would work in 16 bit more - 565 and just
> >> > convert to 18 bit. i.e. the composition happens at 16 bit, not 32. It's
>
> >> What's the point of using a 18-bits framebuffer if most graphics are
> >> done in 16-bits? I assumed, the goal would be to take advantage of the
> >> extra 2 bits
>
> >> > definitely an overhead though. Is the screen update done via an
> >> > eglSwapBuffers call on a single composited surface representing the
>
> >> screen?
>
> >> yes
>
> >> > It might not take very long to try it? and could be faster than the
> >> > overheads bought about by dealing in 18 bit or 32 bit land when rendering
> >> > (more bandwidth needed - particularly if pixels are touched multiple
> >> > times). No obvious winner - it just might be quick to try.
>
> >> > Presumably the rendering routines in the software GL library would also
> >> > have to be modified (unless the platform is using hardware).
>
> >> No, in this scenario, they would be rendering into a 565 buffer as
> >> usual, which would be composited in 565, and eventually converted to
> >> 666 during eglSwapBuffers(). GL doesn't need to be changed, just the
> >> implementation of the EGLNativeWindowType.
>
> >> Unless the panel cannot be configured to 565 (that would be crazy), I
> >> wouldn't go down that road, if it's not going to improve visual
> >> quality.
>
> >> > Mathias Agopian
> >> > <[EMAIL PROTECTED]
> >> > gle.com> To
> >> > Sent by: android-porting@googlegroups.com
> >> > [EMAIL PROTECTED] cc
> >> > ooglegroups.com
> >> > Subject
> >> > [android-porting] Re: Android
> >> > 02/12/2008 09:43 porting problem - LCD BPP
>
> >> > Please respond to
> >> > [EMAIL PROTECTED]
> >> > ooglegroups.com
>
> >> > On Tue, Dec 2, 2008 at 1:25 AM, Phil HUXLEY <[EMAIL PROTECTED]>
> >> wrote:
> >> >> 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'?
>
> >> > I think this would be slower generally. You'd end up doing all the
> >> > composition in 32-bits, and then doing another copy/conversion by
> >> > hand. I don't think it buys you anything. Also this would not match
> >> > the EGL model very well, which SurfaceFlinger (very purposedly) relies
> >> > on.
>
> >> > In my experience update regions don't buy you much because the case
> >> > you care about is when you're "flinging" a list and that tends to
> >> > update the whole screen; surfaceflinger uses them though.
>
> >> > I should have mentioned in the email before that pixelflinger has some
> >> > logic to be able to replace the generated code by hand-written
> >> > routines (see scanline.cpp). You'd want to do this for a few common
> >> > operations like: RGBA32 -> RGB18 with and without blending. I think
> >> > the code it'll generate won't be bad at all, but you'll be able to use
> >> > pld() and/or process several pixels at a time.
>
> >> > One of the annoying part will be to chose a new constant for the new
> >> > format. The namespace for those is limited and global to the platform
> >> > (there are no way -yet- to create pixel formats dynamically at runtime
> >> > -- which the codegen should be able to handle). We just need to be
> >> > absolutely sure that whichever value we pick won't conflict with
> >> > future version of the platform (I already added a few formats post
> >> > 1.0).
>
> >> > Mathias
>
> >> >> Mathias Agopian
> >> >> <[EMAIL PROTECTED]
> >> >> gle.com>
> >> To
> >> >> Sent by: android-porting@googlegroups.com
> >> >> [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
>
> >> > ForwardSourceID:NT000040F6
>
> >> ForwardSourceID:NT0000410E- 隐藏被引用文字 -
>
> >> - 显示引用的文字 -- 隐藏被引用文字 -
>
> - 显示引用的文字 -
--~--~---------~--~----~------------~-------~--~----~
unsubscribe: [EMAIL PROTECTED]
website: http://groups.google.com/group/android-porting
-~----------~----~----~----~------~----~------~--~---
