In my opinion, RGB means red in the high byte and blue in the low byte. But it seems that andriod use red in the low byte and blue in the high byte. I modified the code of load_store.cpp to exchange red and green. Now the display is Ok. Thank you very much.
On 12月3日, 下午5时20分, Mathias Agopian <[EMAIL PROTECTED]> wrote: > 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 > > ... > > 阅读更多 >>- 隐藏被引用文字 - > > - 显示引用的文字 - --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [EMAIL PROTECTED] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
