Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Can't use GL layers on Samsung Galaxy S II: "I/Gecko ( 2827): Failed to create EGL config!"

RESOLVED FIXED in mozilla9

Status

()

Core
Graphics
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: cjones, Assigned: cjones)

Tracking

Trunk
mozilla9
ARM
Android
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [inbound])

Attachments

(1 attachment)

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 3

6 years ago
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.
Whiteboard: [inbound]

Comment 6

6 years ago
https://hg.mozilla.org/mozilla-central/rev/1431db818666
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla9
You need to log in before you can comment on or make changes to this bug.