Quoting Chris Wilson (2018-09-05 16:31:16)
> Since this is handling user provided bpp and depth, we need to sanity
> check and propagate the EINVAL back rather than assume what the insane
> client intended and fill the logs with DRM_ERROR.
> 
> v2: Check both bpp and depth match the builtin pixel format, and
> introduce a canonical DRM_FORMAT_INVALID to reserve 0 against any future
> fourcc.
> 
> v3: Mark up DRM_FORMAT_C8 as being {bpp:8, depth:8}
> 
> Testcase: igt/kms_addfb_basic/legacy-format
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
> Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
> Cc: Michel Dänzer <michel.daen...@amd.com>
> Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>

Pushed the sanity check. Hopefully we are all happy with
DRM_FORMAT_C8:          {bpp:8,  depth:8}
DRM_FORMAT_XRGB1555:    {bpp:16, depth:15}
DRM_FORMAT_RGB565:      {bpp:16, depth:16}
DRM_FORMAT_RGB888:      {bpp:24, depth:24}
DRM_FORMAT_XRGB8888:    {bpp:32, depth:24}
DRM_FORMAT_XRGB2101010: {bpp:32, depth:30}
DRM_FORMAT_ARGB8888:    {bpp:32, depth:32}

Thanks,
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Reply via email to