Last Comment Bug 688115 - Can't use GL layers on Samsung Galaxy S II: "I/Gecko ( 2827): Failed to create EGL config!"
: Can't use GL layers on Samsung Galaxy S II: "I/Gecko ( 2827): Failed to cre...
Status: RESOLVED FIXED
[inbound]
:
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: ARM Android
: -- normal (vote)
: mozilla9
Assigned To: Chris Jones [:cjones] inactive; ni?/f?/r? if you need me
:
: Milan Sreckovic [:milan]
Mentors:
Depends on:
Blocks: opengl-mobile
  Show dependency treegraph
 
Reported: 2011-09-21 01:42 PDT by Chris Jones [:cjones] inactive; ni?/f?/r? if you need me
Modified: 2011-09-23 20:59 PDT (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Try harder to find EGLConfigs (9.79 KB, patch)
2011-09-21 03:06 PDT, Chris Jones [:cjones] inactive; ni?/f?/r? if you need me
ajuma.bugzilla: review+
Details | Diff | Splinter Review

Description Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2011-09-21 01:42:08 PDT
The problem here is that GLContextProviderEGL is hard-coded to only search for a r5g6b5 EGLConfig and bails if one isn't found.  That's fine, except the sgs2 has a 24-bit color display, and apparently doesn't want to use 5-6-5 with the android window.

We still would probably prefer 5-6-5 in general for memory bandwidth savings, if available.  But the sgs2 only supporting r8g8b8a8 configs for windows raises questions about other "MOZ_GFX_OPTIMIZE_MOBILE => 5-6-5 better" assumptions.  We can investigate the more general questions in bug 688104.

This patch should be pretty simple.
Comment 1 Florian Hänel [:heeen] 2011-09-21 02:15:15 PDT
See also bug 687835
Comment 2 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2011-09-21 03:06:34 PDT
Created attachment 561419 [details] [diff] [review]
Try harder to find EGLConfigs

The first problem here was a failure to create an EGLConfig.  I thought 565 was a problem because when I commented out the MOBILE_OPTIMIZE code things worked.  However, when I added back the ability to prefer-565-but-use-8888, then things stopped working again.  eglChooseConfig() was returning a null config as if it were valid.  There's nothing that says a null config is *in*valid, AFAICT, so I made the code here not assume null => invalid.  Problem was, after that things were *still* broken, but this time deeper in android

E/Surface ( 2825): surface (identity=5) is invalid, err=-19 (No such device)
E/Surface ( 2825): surface (identity=5) is invalid, err=-19 (No such device)
E/        ( 2825): EGL unable to dequeue buffer in EGLBoolean __egl_platform_create_surface_window(egl_surface*, mali_base_ctx_type*)
I/Gecko   ( 2825): got surface 0x0

I noticed that we weren't checking the return value of eglGetConfigAttrib() so added those checks.  (Maybe null is actually invalid but is still being returned as valid for some reason ...)  Anyway, to make a long story short, GL works now.  I'm not sure whether the context is grabbing a 565 EGLConfig or 8888, but it doesn't really matter wrt this bug.
Comment 3 Ali Juma [:ajuma] 2011-09-21 10:30:49 PDT
Comment on attachment 561419 [details] [diff] [review]
Try harder to find EGLConfigs

Review of attachment 561419 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good!
Comment 4 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2011-09-21 21:41:55 PDT
Turns out that this patch is necessary but not sufficient with m-c tip.  Something else changed in the widget backend that's blocking the Mali-400 to be blocked.  (I wrote this patch against an older m-c rev.)  Looking.
Comment 5 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2011-09-21 21:46:26 PDT
Never mind, had disabled=true by accident.  All's well on m-c tip.
Comment 6 Ed Morley [:emorley] 2011-09-23 20:59:49 PDT
https://hg.mozilla.org/mozilla-central/rev/1431db818666

Note You need to log in before you can comment on or make changes to this bug.