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

[Rob Herring]

On Fri, May 19, 2017 at 12:57 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 18 May 2017 at 23:01, Rob Herring <robh at kernel.org> wrote:
>> 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?
>>
> Having a short/mid term ifdef ANDROID is perfectly fine.
>
> Can we address some of the existing ones before/alongside the newly added ones?
> Afacit the nouveau bits are no longer applicable.

Yeah. I don't explicitly warn for KK or less, but will add that and fix these.

> While for the
> gbm/egl 'use "gallium_dri.so"' one can either use your latest build
> rework or MESA_LOADER_DRIVER_OVERRIDE.

How does the build rework help? My only reservation with using an env
var is generally Android things don't rely on them and it would break
working systems. I'm not even completely certain I can set env vars
globally. It would be nice if the build system could set defaults for
env vars we could use.

Rob