Greeting, Now 16 BPP is used at FB driver and surface flinger, but blue color has more weight on the display, I don't know why? The 16 BPP format is: RRRRRGGGGGGBBBBB (RGB565) in the fb driver, is the surface flinger different data format with driver?Thanks! Mark
On Dec 4, 12:47 pm, Mathias Agopian <[EMAIL PROTECTED]> wrote: > 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: > >> >> >> [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. > > ... > > read more >>- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [EMAIL PROTECTED] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
