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.
See also bug 687835
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.
Assignee: nobody → jones.chris.g
Attachment #561419 - Flags: review?(ajuma)
Comment on attachment 561419 [details] [diff] [review] Try harder to find EGLConfigs Review of attachment 561419 [details] [diff] [review]: ----------------------------------------------------------------- Looks good!
Attachment #561419 - Flags: review?(ajuma) → review+
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.
Never mind, had disabled=true by accident. All's well on m-c tip.
8 years ago
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla9
You need to log in before you can comment on or make changes to this bug.