On Tue, Jul 11, 2017 at 11:16 PM, Rob Herring <[email protected]> wrote: > On Tue, Jul 11, 2017 at 8:27 AM, Emil Velikov <[email protected]> > wrote: >> From: Emil Velikov <[email protected]> >> >> As said in the EGL_KHR_platform_android extensions >> >> For each EGLConfig that belongs to the Android platform, the >> EGL_NATIVE_VISUAL_ID attribute is an Android window format, such as >> WINDOW_FORMAT_RGBA_8888. >> >> Although it should be applicable overall. >> >> Even though we use HAL_PIXEL_FORMAT here, those are numerically >> identical to the WINDOW_FORMAT_ and AHARDWAREBUFFER_FORMAT_ ones. >> >> Barring the said format of course. That one is only listed in HAL. >> >> Keep in mind that even if we try to use the said format, you'll get >> caught by droid_create_surface(). The function compares the format of >> the underlying window, against the NATIVE_VISUAL_ID of the config. >> >> Unfortunatelly it only prints a warning, rather than error out, likely >> leading to visual corruption. >> >> While SDL will even call ANativeWindow_setBuffersGeometry() with the >> wrong format, and conviniently ignore the [expected] failure. >> >> Cc: [email protected] >> Cc: Chad Versace <[email protected]> >> Cc: Tomasz Figa <[email protected]> >> Signed-off-by: Emil Velikov <[email protected]> >> --- >> I'm about 99.99% sure the above is correct, but I haven't tested it. > > Isn't this going to break if there's no driver support for RGBA/RGBX > which is the case for stable (and master for gallium drvs).
First of all, Android hardcodes HAL_PIXEL_FORMAT_RGBA_8888 in a number of places, which means that those users use a patched Android. However I'm not sure if we can just break them like this. I'll leave it to you guys, though. Other than that, CTS seems to require only RGBA_8888 and RGB_565, so this change is not going to affect compliance with unpatched Android. Best regards, Tomasz _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
