[PATCH v3 09/15] drm: tilcdc: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp()

[Ville Syrjälä]

On Fri, Jun 10, 2016 at 03:26:30PM +0300, Tomi Valkeinen wrote:
> On 10/06/16 15:23, Ville Syrjälä wrote:
> > On Fri, Jun 10, 2016 at 03:08:18PM +0300, Tomi Valkeinen wrote:
> >> On 10/06/16 15:05, Ville Syrjälä wrote:
> >>
> >>>> I'm not sure what's the common way, but tilcdc doesn't support alpha.
> >>>> ARGB works, of course, by ignoring A, but... If an userspace app creates
> >>>> ARGB buffer, does the app expect alpha to work?
> >>>
> >>> I think what we decided a while ago (at least for i915, but would be good
> >>> to use the same convention everywhere) was that ARGB will be assumed to be
> >>> pre-multiplied and will enable blending using 1.0*sc+(1.0-sa)*dc as the
> >>> function. There have been some efforts at defining some new properties to
> >>> control the blend equation, but I guess those got bogged down again.
> >>
> >> Ok, but that's a bit different topic. The question here is, if the HW
> >> doesn't support alpha (no planes, so nothing to blend), should it accept
> >> ARGB or not.
> > 
> > What do you mean "no planes"? You have to have a plane if you want
> > to scanout a framebuffer. And even if you have just one plane with
> > alpha blending, it should be blended with the background color
> > (which is black until we get a property to change it).
> 
> I mean there's only the crtc with fb. So yes, one plane if you want to
> call that a plane.

We do ;)

> The HW does not support any kind of blending to black
> or to anything else.

Right. Then formats with alpha shouldn't be advertized.

-- 
Ville Syrjälä
Intel OTC