Quoting Chris Wilson (2018-09-05 11:22:05)
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.
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
drivers/gpu/drm/drm_fourcc.c | 33 +++++++++++++++++++++---------- drivers/gpu/drm/drm_framebuffer.c | 7 ++++++- include/uapi/drm/drm_fourcc.h | 3 +++ 3 files changed, 32 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c index 35c1e2742c27..d9dadbc43327 100644 --- a/drivers/gpu/drm/drm_fourcc.c +++ b/drivers/gpu/drm/drm_fourcc.c @@ -45,32 +45,45 @@ static char printable_char(int c) */ uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth) {
uint32_t fmt;
uint32_t fmt = DRM_FORMAT_INVALID; switch (bpp) { case 8:
fmt = DRM_FORMAT_C8;
if (depth == 0)fmt = DRM_FORMAT_C8;
Of course the downside with increasing specificity is if any userspace was already feeding in garbage depth that just happens to work :( -Chris