Hey Rob, On Mon, 2017-11-27 at 13:42 -0600, Rob Herring wrote: > On Mon, Nov 27, 2017 at 8:14 AM, Robert Foss <robert.foss@collabora.c > om> wrote: > > From: Tomasz Figa <tf...@chromium.org> > > > > There is no API available to properly query the > > IMPLEMENTATION_DEFINED > > format. As a workaround we rely here on gralloc allocating either > > an arbitrary YCbCr 4:2:0 or RGBX_8888, with the latter being > > recognized > > by lock_ycbcr failing. > > > > Reviewed-on: https://chromium-review.googlesource.com/566793 > > > > Signed-off-by: Tomasz Figa <tf...@chromium.org> > > Reviewed-by: Chad Versace <chadvers...@chromium.org> > > Signed-off-by: Robert Foss <robert.f...@collabora.com> > > --- > > src/egl/drivers/dri2/platform_android.c | 39 > > +++++++++++++++++++++++++++++++-- > > 1 file changed, 37 insertions(+), 2 deletions(-) > > > > diff --git a/src/egl/drivers/dri2/platform_android.c > > b/src/egl/drivers/dri2/platform_android.c > > index 63223e9a69..ae914d79c1 100644 > > --- a/src/egl/drivers/dri2/platform_android.c > > +++ b/src/egl/drivers/dri2/platform_android.c > > @@ -59,6 +59,10 @@ static const struct droid_yuv_format > > droid_yuv_formats[] = { > > { HAL_PIXEL_FORMAT_YCbCr_420_888, 0, 1, > > __DRI_IMAGE_FOURCC_YUV420 }, > > { HAL_PIXEL_FORMAT_YCbCr_420_888, 1, 1, > > __DRI_IMAGE_FOURCC_YVU420 }, > > { HAL_PIXEL_FORMAT_YV12, 1, 1, > > __DRI_IMAGE_FOURCC_YVU420 }, > > + /* HACK: See droid_create_image_from_prime_fd() and b/32077885. > > */ > > + { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED, 0, 2, > > __DRI_IMAGE_FOURCC_NV12 }, > > + { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED, 0, 1, > > __DRI_IMAGE_FOURCC_YUV420 }, > > + { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED, 1, 1, > > __DRI_IMAGE_FOURCC_YVU420 }, > > }; > > > > static int > > @@ -90,6 +94,11 @@ get_format_bpp(int native) > > > > switch (native) { > > case HAL_PIXEL_FORMAT_RGBA_8888: > > + case HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED: > > + /* > > + * HACK: Hardcode this to RGBX_8888 as per cros_gralloc > > hack. > > Does this work with other grallocs?
Not necessarily, it is implementation specific. The implementation specific part is lock_ycbcr() failing for non YUV formats, which allows the application to disambiguate between YCbCr 4:2:0 or RGBX_8888. > > > + * TODO: Remove this once b/32077885 is fixed. > > Is that a public bug? A full url would be better if so. Unfortunately it isn't, I maintained the link since it is better than nothing. And to be clear, I don't have access to that URL either at this moment. Rob.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev