On Thu, Mar 20, 2014 at 11:38:18AM +0000, Damien Lespiau wrote: > On Thu, Mar 20, 2014 at 03:29:42PM +0530, Sagar Arun Kamble wrote: > > Hi Damien, > > > > On Wed, 2014-03-19 at 15:10 +0000, Damien Lespiau wrote: > > > On Sat, Mar 08, 2014 at 01:51:18PM +0530, sagar.a.kamble@xxxxxxxxx wrote: > > > > From: Sagar Kamble <sagar.a.kamble@xxxxxxxxx> > > > > > > > > This patch enables property for changin the pixel format > > > > of plane to enable/disable pre-multiplied alpha format. > > > > Client has to set BIT(DRM_BLEND_PREMULTIPLIED_ALPHA) | 0x0/0x1 > > > > to disable/enable pre-multiplied alpha format. > > > > > > > > Cc: Daniel Vetter <daniel.vetter@xxxxxxxx> > > > > Cc: Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> > > > > Cc: David Airlie <airlied@xxxxxxxx> > > > > Signed-off-by: Srinivas, Vidya <vidya.srinivas@xxxxxxxxx> > > > > Signed-off-by: Sagar Kamble <sagar.a.kamble@xxxxxxxxx> > > > > > > Huum, the alpha being premultiplied or not seems to be a property of the > > > framebuffer to me, not of the plane. It seems to me that we should > > > define alternative premultiplied DRM_FORMATs and make the sprite planes > > > advertise support for premultiplied fbs in the format list when the > > > hardware indeed supports them. > > This is what i think of usage of this property: > > > > Composer/user mode starts using plane with XRGB format and then it wants > > to add transparency to the plane. So it will set the format to ARGB > > format and provide buffer for that plane that will have pixels with > > pre-multiplied alpha (a*r, a*g, a*b, a). > > This can be done with primary plane(CRTC) as well, however I have > > not added this as CRTC property since CRTCs are going to be drm_plane > > soon. > > > > Will this kind of interface for usermode to toggle the pixel format's > > alpha be useful? > > I don't think so, nop. > > Besides being a convoluted apocalyptic scenario, one cannot simply > change the format of the FB without re-adding it with AddFB2(). > > There's a usage model for the compositor to add a plane-global alpha to > a plane (fades the client provided render target) and that's indeed a > plane property. > > As far I as can tell, the premultiplied alpha format ban be sued support > scanning out OpenGL blended fbs. I'm not sure I follow this discussion completely, but in my opinion may _never_ change the pixel format of a drm framebuffer object. Think of a drm framebuffer as a view of the underlying object(s) with strides, pixel format, dimensions and other stuff specified. If you need a different view, simply create a new drm framebuffer object. Note that drm framebuffer objects are never shared (as opposed to the underlying gem backing storage which can be shared with flink or dma-buf), so this doesn't need any synchronization outside of the compositor itself. I don't really have a decent opinion on the pre-multiplied vs non-premultiplied ARGB formats issue at hand. In case of doubt I think we should follow what gl does. But I have no clue how that's handled in gl ;-) And maybe I'm completely missing the point here ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
