[Mesa-dev] [PATCH 0/3] Support for Android RGBX/RGBA formats

[Emil Velikov]

On 24 April 2016 at 15:41, Chih-Wei Huang <cwhuang at android-x86.org> wrote:
> 2016-04-24 21:50 GMT+08:00 Emil Velikov <emil.l.velikov at gmail.com>:
>> On 24 April 2016 at 14:20, Marek Olšák <maraeo at gmail.com> wrote:
>>> On Sun, Apr 24, 2016 at 3:09 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>>> On Sun, Apr 24, 2016 at 2:16 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>>>> On Fri, Apr 22, 2016 at 12:41 PM, Chih-Wei Huang
>>>>> <cwhuang at android-x86.org> wrote:
>>>>>> 2016-04-21 21:42 GMT+08:00 Emil Velikov <emil.l.velikov at gmail.com>:
>>>>>>>
>>>>>>> On 19 April 2016 at 20:38, Rob Herring <robh at kernel.org> wrote:
>>>>>>>> The RGBX/RGBA pixel formats used in the Android EGL don't get configs
>>>>>>>> created due to the missing formats in the DRI state tracker. This series
>>>>>>>> adds the necessary formats for configs and DRI images. Support in GBM is
>>>>>>>> also added as it will be needed soon for Android.
>>>>>>>>
>>>>>>>> AFAICT, this has been a long standing bug in Android-x86 which was
>>>>>>>> worked around with the patch "GLSurfaceView: Be less picky about
>>>>>>>> EGLConfig alpha sizes". With this series, this patch is no longer needed
>>>>>>>> and several other bugs like wallpaper not getting displayed are fixed.
>>>>>>>>
>>>>>>> In the past similar changes has caused unexpected bugs and/or pert regressions.
>>>>>>>
>>>>>>> Although I doubt we'll notice them with the patches on the ML, thus
>>>>>>> I've pushed the lot to get some wider testing.
>>>>>>>  Please keep an eye for fires ;-)
>>>>>>
>>>>>> Could these be back-ported to 11.2?
>>>>>
>>>>> DEFINITELY NOT.
>>>>>
>>>>> It's too risky and it has already broken GLX.
>>>>
>>>> OK so the problem is libGL ignores the red/green/blue mask, therefore
>>>> it doesn't distinguish between BGRA and RGBA. Also, DRI always assumes
>>>> it's BGRA on the X server side. This patch series also ignores the
>>>> red/green/blue mask for imported buffers. That's why DRI2 mostly
>>>> works. I haven't tested DRI3.
>>>>
>>>> libGL could be fixed not to expose RGBA visuals, but that's
>>>> insufficient, because Mesa drivers must be loadable by older libGL
>>>> too.
>>>>
>>>> The bottom line is st/dri can't expose RGBA, because it would break
>>>> Mesa with old libGL.
>>>>
>> Speaking of which... I while back I was asking/proposing that we
>> deprecate 'too old' loader (libGL) <> dri modules combos. Something
>> like ~3 year difference came to mind (functionality based). Do we have
>> (m)any people who explicitly test dri module from today and libGL form
>> 5-6, 10 years ago ?
>>>>
>> Ack. Thanks for looking into it Marek !
>>
>> Emil
>
>> How do you feel on the topic ?
>>
>>>> Unless you guys come up with a solution, I'll have to revert the st/dri change.
>>>
>>> FYI, I've decided to revert the st/dri commit now to fix the KDE
>>> issue.
>
> Why not just limit this commit to Android only?
> The RGBA is possibly only used by Android?
>
I won't object if we keep it under some form of a switch - be that
envvar, compile guard or others.  If we cannot afford the android/cros
approach and enforce and "X must run with Y"

> Android-x86 community has waited such a fix
> for a very long time.
> Don't just drop it because it breaks others.
>
Sadly 'others' is the fast majority, so you can see why it was nuked.

Although I think I can avoid the nasty solutions proposed above - just
wire up a new flag to __DRIimageExtension::getCapabilities. This way
loaders will probe the DRI module if it's ok with RGBX/RGBA formats
keeping everyone happy ?

-Emil