[PATCH] drm/vc4: Ignore alpha on primary plane

[Ville Syrjälä]

On Fri, Mar 02, 2018 at 04:48:03PM +0100, Stefan Schake wrote:
> On Fri, Mar 2, 2018 at 4:21 PM, Ville Syrjälä
> <ville.syrjala at linux.intel.com> wrote:
> > On Fri, Mar 02, 2018 at 04:06:58PM +0100, Stefan Schake wrote:
> >> Hey Ville,
> >>
> >> On Fri, Mar 2, 2018 at 3:43 PM, Ville Syrjälä
> >> <ville.syrjala at linux.intel.com> wrote:
> >> > On Fri, Mar 02, 2018 at 04:39:22PM +0200, Ville Syrjälä wrote:
> >> >> If you want the plane to always be opaque you shouldn't expose any
> >> >> formats with alpha.
> >> >>
> >> >> Also what happens if one disables the primary plane? Or does the driver
> >> >> not allow that?
> >> >
> >> > Or just makes the plane not cover the entire screen?
> >>
> >> We've exposed alpha formats in the past so disabling that now would break
> >> userspace, certainly Android that chooses alpha-everything.
> >
> > So it refuses to even run on hardware that can't do per-pixel alpha on
> > the primary plane?
> 
> Well since we have no real primary plane we'd have to remove support from
> every plane or add elaborate logic to atomic check that detects and rejects
> a configuration that has pixels blending from nothing, which presumably is
> what triggers the display artifacts.
> 
> >> The VC4 HVS
> >> has no fixed planes so I'll acknowledge that the concept of a primary plane
> >> is somewhat dubious and userspace could disable it or make it not cover the
> >> entire screen, making this ineffective.
> >>
> >> But then ultimately there doesn't seem to be a standard for what the display
> >> is supposed to be if you have transparent pixels with no plane to blend to
> >> below.
> >
> > The standard is black. IMO it's a driver bug if it fails to do that.
> 
> Then to be sure we should always enable the background fill. Maybe Eric can
> clarify what the cost for this is, all I have to go on there is the comment
> on the register set.

Yeah, that sounds like the correct thing to do.

-- 
Ville Syrjälä
Intel OTC