On Fri, May 19, 2017 at 12:57 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 18 May 2017 at 23:01, Rob Herring <r...@kernel.org> wrote: >> On Thu, May 18, 2017 at 5:25 AM, Emil Velikov <emil.l.veli...@gmail.com> >> wrote: >>> On 18 May 2017 at 05:10, Chih-Wei Huang <cwhu...@android-x86.org> wrote: >>>> 2017-05-18 12:01 GMT+08:00 Xu, Randy <randy...@intel.com>: >>>>> >>>>>> -----Original Message----- >>>>>> From: Palli, Tapani >>>>>> > >>>>>> > It's just applied. Isn't it? >>>>>> > Yesterday without this patch >>>>>> > the color format is mismatch apparently. >>>>>> >>>>>> Yeah we do need this. TBH I don't quite understand why but will try to >>>>>> figure >>>>>> it out. I remember we used to have a patch in Surfaceflinger at one point >>>>>> because visual was hardcoded there and this might be related. >>>>>> >>>>>> // Tapani >>>>> >>>>> Sorry, that's for different issue, I mix it with RGB565 blending one. >>>>> This patch is required because some Android GLES test apps, like >>>>> gl2_basic, need to create RGBA8888 surface. >>>> >>>> Indeed it is. >>>> >>>> As Emil pointed out, the patch was merged before >>>> but reverted later since it broke desktop. >>>> >>>> So what's the current upstreaming plan? >>>> >>> No idea about a plan, but how you can fix it once and for all: >>> >>> Extend the loader extension(s) to have a get_caps() callback, >>> analogous to __DRIimageExtension::getCapabilities. >>> Then the DRI module will query [the loader] and advertise the >>> RGBX/RGBA visuals when possible. >> >> Could we do something compile time instead to enable just for Android? >> Seems like a lot of complexity when the platform needing these pixel >> formats doesn't need the backwards compatibility. Or maybe there are >> other things needing this interface? >> > Having a short/mid term ifdef ANDROID is perfectly fine. > > Can we address some of the existing ones before/alongside the newly added > ones? > Afacit the nouveau bits are no longer applicable.
Yeah. I don't explicitly warn for KK or less, but will add that and fix these. > While for the > gbm/egl 'use "gallium_dri.so"' one can either use your latest build > rework or MESA_LOADER_DRIVER_OVERRIDE. How does the build rework help? My only reservation with using an env var is generally Android things don't rely on them and it would break working systems. I'm not even completely certain I can set env vars globally. It would be nice if the build system could set defaults for env vars we could use. Rob _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
