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 chris@chris-wilson.co.uk Cc: Daniel Vetter daniel.vetter@ffwll.ch Cc: Ville Syrjälä ville.syrjala@linux.intel.com Cc: Michel Dänzer michel.daenzer@amd.com Reviewed-by: Daniel Vetter daniel.vetter@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