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? Rob _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
