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

[Marek Olšák]

On Sun, Apr 24, 2016 at 7:06 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> 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 ?

Well, it is the DRI modules that need to be told that it's okay to
expose RGBA. You need a function that will send such a message to
those modules before visuals are queried.

Speaking of the compatibility with old libGL, I don't care about it,
but there are others who care, such as Red Hat.

Marek