On Fri, Mar 2, 2018 at 4:21 PM, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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. Thanks, Stefan _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
