On Sun, Apr 24, 2016 at 7:06 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 24 April 2016 at 15:41, Chih-Wei Huang <cwhu...@android-x86.org> wrote: >> 2016-04-24 21:50 GMT+08:00 Emil Velikov <emil.l.veli...@gmail.com>: >>> On 24 April 2016 at 14:20, Marek Olšák <mar...@gmail.com> wrote: >>>> On Sun, Apr 24, 2016 at 3:09 PM, Marek Olšák <mar...@gmail.com> wrote: >>>>> On Sun, Apr 24, 2016 at 2:16 PM, Marek Olšák <mar...@gmail.com> wrote: >>>>>> On Fri, Apr 22, 2016 at 12:41 PM, Chih-Wei Huang >>>>>> <cwhu...@android-x86.org> wrote: >>>>>>> 2016-04-21 21:42 GMT+08:00 Emil Velikov <emil.l.veli...@gmail.com>: >>>>>>>> >>>>>>>> On 19 April 2016 at 20:38, Rob Herring <r...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
