On Fri, Mar 2, 2018 at 4:21 PM, Ville Syrjälä
<ville.syrj...@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.syrj...@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.

dri-devel mailing list

Reply via email to