> a) inlined kernel patch to refuse getfb for modifiers we can't determine via
> implicit means, or multi-planar
Your provided kernel patch replaces the corruption with blackness, which was probably expected. So the seamless transition from gdm3 into gnome-shell (or whatever) is gone. We can achieve the same blackness workaround by removing '-background none' from the gdm3 source, but that hurts all users including Broadwell and earlier who are not yet affected by the bug.
> 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
It's gdm3 so the code you want is mutter, right? I think we'd lean more toward patching the offending commit out of Mesa before we go proposing more mutter patches. I'm hesitant to do either right now. New ideas are welcome.
(In reply to Daniel Stone from comment #13)
> a) inlined kernel patch to refuse getfb for modifiers we can't determine via
> implicit means, or multi-planar
Your provided kernel patch replaces the corruption with blackness, which was probably expected. So the seamless transition from gdm3 into gnome-shell (or whatever) is gone. We can achieve the same blackness workaround by removing '-background none' from the gdm3 source, but that hurts all users including Broadwell and earlier who are not yet affected by the bug.
> b) in whatever your DM (GDM? LightDM?) uses to create a KMS display, MOD_LINEAR / MOD_X_TILED / I915_FORMAT_ MOD_Y_TILED
> filtering the supported modifier set to DRM_FORMAT_
> I915_FORMAT_
It's gdm3 so the code you want is mutter, right? I think we'd lean more toward patching the offending commit out of Mesa before we go proposing more mutter patches. I'm hesitant to do either right now. New ideas are welcome.