As far as I can tell from a quick inspection of the code, pixelflinger reads and outputs RGB24 formats as R,G,B as it should.
Are you sure your framebuffer takes RGB and not BGR? Also are you using "PIXEL_FORMAT_RGB_888" when initializing the frame-buffer surface? you can see the routines in pixelflinger/codeflinger/load_store.cpp mathias On Wed, Dec 3, 2008 at 12:39 AM, FlyCry <[EMAIL PROTECTED]> wrote: > > 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: [email protected] >> >> [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: [email protected] >> >> > [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: [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 >> >> >> > ForwardSourceID:NT000040F6 >> >> >> ForwardSourceID:NT0000410E- 隐藏被引用文字 - >> >> >> - 显示引用的文字 -- 隐藏被引用文字 - >> >> - 显示引用的文字 - > > > --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [EMAIL PROTECTED] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
