Comment 59 for bug 1753776

That's really odd. -background none will just do GBM_BO_IMPORT_FD (which passes DRM_FORMAT_MOD_INVALID) from the current DRM FB to get a gbm_bo, then import that BO into an EGLImage, which it copies from.

I wonder if the original image we try to import is Y_CCS, but we import it as plain Y (no CCS) because drmModeGetFb doesn't tell us the modifier.

Daniel, do either of the following fix this for your users?

a) inlined kernel patch to refuse getfb for modifiers we can't determine via implicit means, or multi-planar
b) in whatever your DM (GDM? LightDM?) uses to create a KMS display, filtering the supported modifier set to DRM_FORMAT_MOD_LINEAR / I915_FORMAT_MOD_X_TILED / I915_FORMAT_MOD_Y_TILED

I think the kernel patch is the most correct, but then we might have to create a getfb2 to support -background none. :(

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 92d94d2684f4..ef157585fc32 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13934,6 +13934,16 @@ static int intel_user_framebuffer_create_handle(struct drm_framebuffer *fb,
   return -EINVAL;
  }

+ switch (fb->modifier) {
+ case DRM_FORMAT_MOD_LINEAR:
+ case I915_FORMAT_MOD_X_TILED:
+ case I915_FORMAT_MOD_Y_TILED:
+ break;
+ default:
+ DRM_DEBUG_KMS("rejecting getfb for exotic modifier\n");
+ return -EINVAL;
+ }
+
  return drm_gem_handle_create(file, &obj->base, handle);
 }