Hi Lepton, On Thu, Aug 15, 2019 at 9:58 PM Lepton Wu <lep...@chromium.org> wrote:
> That's interesting. The android frame work will hard coded to use > RGBA_8888 and set it as window format here: > > > https://android.googlesource.com/platform/frameworks/native/+/refs/heads/master/opengl/libs/EGL/eglApi.cpp#738 > > Do you have a custom version of android which do different code here? > Affirmative, you may check [1] for reference [1] http://git.osdn.net/view?p=android-x86/frameworks-native.git;a=commit;h=792c8dc009bd3a0c44eb39e757a95e099c03b54c > > For other GPU, like intel, if we choose a EGL config with BGRA , > finally we got a wrong color on screen. > android-x86 implementation selects BGRA_8888 only when RGBA_8888 not available, in a similar way to a pre-existing Workaround 10194508 that was removed from AOSP code Removing HAL_PIXEL_FORMAT_BGRA_8888 support from egl/android SurfaceFlinger will just crash with SIGABRT on nouveau > > On Thu, Aug 15, 2019 at 12:49 PM Mauro Rossi <issor.or...@gmail.com> > wrote: > > > > Hi, > > > > sorry if I'm communicating in dedicated thread, but I don't know how to > reply to existing one. > > > > The proposed patch is based on the wrong assumption that all drivers > used with Android have RGBA_8888, which is not correct, for example nouveau > does not support RGBA on primary planes, infact we have a fallback to > simpler EGL query in android-x86 and we use BGRA_8888 (pixel format = 5) > > > > If patch does not solve a specific problem and it will cause a > regression at least in nouveau, it is recommended to abandon the patch > > > > Thanks for your feedbacks > > > > Mauro >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
