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

[Tomi Valkeinen]

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. The HW does not support any kind of blending to black
or to anything else.

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160610/2b4d12a8/attachment.sig>