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

[Emil Velikov]

On 24 April 2016 at 23:46, Marek Olšák <maraeo at gmail.com> wrote:
> 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.
>
Yes, we want the query in the inverse direction ->
__DRIImageLoaderExtension::getCapabilities. Anyone interested ?

> Speaking of the compatibility with old libGL, I don't care about it,
> but there are others who care, such as Red Hat.
>
Nice, one person that's ok with the idea, next RedHat people

Dave, Adam,

Last a I saw you guys were backporting all of mesa, correct ?
Are you OK with us deprecating compat. between DRI(2) modules and
loaders (GL/EGL/gbm) that are, say 3 years apart ?

Thanks
Emil