Now the picture is complete, and it's better news than the September note suggested. Three things in Firefox's own code:
 

1. There's a fallback chain already, and it's three deep. CreateTexture tries zero-copy import first; if that fails it has CreateTextureViaCopyYUV for NV12 and CreateTextureViaCopyP010 for 10-bit.

2. Those fallbacks already use the external-texture machinery — the exact mechanism a whole-frame import needs:

aGLContext->fBindTexture(LOCAL_GL_TEXTURE_EXTERNAL, srcTex);
aGLContext->fEGLImageTargetTexture2D(LOCAL_GL_TEXTURE_EXTERNAL, mEGLImage[aPlane]);

So Firefox can bind a dma-buf as an external texture. It just does it per plane, as a copy, and only when the buffer is linear.
 

3. Firefox already tracks the whole-frame NV12 format. DMABufFormats.cpp calls EnsureBasicFormat(GBM_FORMAT_NV12), stores its modifiers, and GetDRMFormat() hands that object back — and the YUV path then passes it in while still importing two planes as R8 + GR88.

Why we never reach any of it. The chain starts at CreateYUVPlane, which has to build an EGLImage for plane 1 using GR88. On the Mali blob that format doesn't exist, so the image is never created, and the loop bails before CreateTexture and all three fallbacks. The failure is one step earlier than the recovery code.
 

So, to your question: not commented out, and not missing either. Every ingredient is present — the whole-frame format with its modifiers, the external-texture import, and a precedent for swapping formats when one isn't supported. What's absent is the wiring for the case where both two-channel 8-bit formats are missing but the whole-frame format is there.

That makes a much better upstream report than "please support our driver." It's: your existing fallback tries exactly one alternative; here is a shipping Arm GPU where both alternatives are absent and the whole-frame format you already track is present. With the 41-format list as evidence and a reproducible platform behind it.

Want me to write that up as a Bugzilla report? I'd check first whether it's already filed, and the honest framing is a driver-conformance gap with a suggested fallback, not a demand.
Researched the code with Claude Fable 5
So with any luck Firefox will add the needed ingredients.

Sent off to Bugzilla.... But I want a working copy so I am having them build it.. now they are saying the patch is smaller.
I like having proof of work.. you know sometimes they are not fully accurate. Hopefully a fully functional Firefox by days end.

I had em build the damn thing. I think it was 39 lines of code:
Cool having first

https://bugzilla.mozilla.org/show_bug.cgi?id=2078820

 

Edited Tuesday at 11:34 PM4 days by defcom5-rockchip