On Wed, Dec 3, 2008 at 8:37 PM, FlyCry <[EMAIL PROTECTED]> wrote: > > 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.
The notion of "high" byte and "low" byte in a 24-bits frame buffer is a little odd. Since these are not 32 bits or 16 bits numbers, I'm not sure what you mean. I stand by what I said, android supports RGB, in that order. One byte of red, one byte of green, followed by one byte of blue. R,G,B... btw, this order happens to be OpenGL's GL_RGB internal format for textures. You *cannot* change load_store.cpp like that, you have now broken OpenGL's glTexImage2D() :-( Mathias > > 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: 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 >> >> ... >> >> 阅读更多 >>- 隐藏被引用文字 - >> >> - 显示引用的文字 - > > > --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [EMAIL PROTECTED] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
