[Mesa-dev] [PATCH] i965: Add RGBX8888 and RGBA8888 to EGL configure and reorder the list

Rob Herring robh at kernel.org
Thu May 18 22:01:16 UTC 2017


On Thu, May 18, 2017 at 5:25 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 18 May 2017 at 05:10, Chih-Wei Huang <cwhuang at android-x86.org> wrote:
>> 2017-05-18 12:01 GMT+08:00 Xu, Randy <randy.xu at intel.com>:
>>>
>>>> -----Original Message-----
>>>> From: Palli, Tapani
>>>> >
>>>> > It's just applied. Isn't it?
>>>> > Yesterday without this patch
>>>> > the color format is mismatch apparently.
>>>>
>>>> Yeah we do need this. TBH I don't quite understand why but will try to figure
>>>> it out. I remember we used to have a patch in Surfaceflinger at one point
>>>> because visual was hardcoded there and this might be related.
>>>>
>>>> // Tapani
>>>
>>> Sorry, that's for different issue, I mix it with RGB565 blending one.
>>> This patch is required because some Android GLES test apps, like gl2_basic, need to create RGBA8888 surface.
>>
>> Indeed it is.
>>
>> As Emil pointed out, the patch was merged before
>> but reverted later since it broke desktop.
>>
>> So what's the current upstreaming plan?
>>
> No idea about a plan, but how you can fix it once and for all:
>
> Extend the loader extension(s) to have a get_caps() callback,
> analogous to __DRIimageExtension::getCapabilities.
> Then the DRI module will query [the loader] and advertise the
> RGBX/RGBA visuals when possible.

Could we do something compile time instead to enable just for Android?
Seems like a lot of complexity when the platform needing these pixel
formats doesn't need the backwards compatibility. Or maybe there are
other things needing this interface?

Rob


More information about the mesa-dev mailing list