On 24 April 2016 at 23:46, Marek Olšák <mar...@gmail.com> wrote: > 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. > 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
