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

[Tapani Pälli]

On 05/19/2017 04:19 AM, Xu, Randy wrote:
>> -----Original Message-----
>> From: Rob Herring [mailto:robh at kernel.org]
>> Sent: Friday, May 19, 2017 6:01 AM
>> To: Emil Velikov <emil.l.velikov at gmail.com>
>> Cc: Chih-Wei Huang <cwhuang at android-x86.org>; ML mesa-dev <mesa-
>> dev at lists.freedesktop.org>; Xu, Randy <randy.xu at intel.com>
>> Subject: Re: [Mesa-dev] [PATCH] i965: Add RGBX8888 and RGBA8888 to EGL
>> configure and reorder the list
>>
>> 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?
> 
> I also wish that, can we use macro, like "#if ANDROID" ?
> It's not necessary to enable these two visuals for all platform, but it's really important for Android.

IMO we should fix Android instead, there is no reason why it would 
*require* these formats.

// Tapani