Comment 61 for bug 1753776

(In reply to Daniel van Vugt from comment #14)
> (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.

Correct.

> > 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.

That's not a long-term fix I'm suggesting, but to very specifically narrow down the problem, i.e. prove the thesis that the issue is caused by attempting to infer the tiling layout of a framebuffer with auxiliary compression planes. The whitelist I suggested would make sure Mutter only picks single-plane formats: if that results in the corruption disappearing, then we know the problem is exactly that and nothing else.

There are exactly three options to fix this:
  a) stop using -background none (I didn't notice this since my DM launches a Wayland session, and Xorg is something I only start from a VT without bg none); or
  b) revert the Mesa commit and take a hit from not having renderbuffer compression enabled; or
  c) add a GetFB2 ioctl to the kernel + libdrm which includes multi-planar and modifier information, use that in Xorg as well as a modifier-aware gbm_bo import interface.

The latter is obviously the most complete, but it's not zero work.