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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
