On Wed, Feb 19, 2014 at 03:38:08PM +0530, sagar.a.kamble@xxxxxxxxx wrote: > From: Sagar Kamble <sagar.a.kamble@xxxxxxxxx> > > With this patch two properties are added. One for CRTC+Sprite planes > and another for Cursor planes. Through these client will be able to > change the pixel format of the planes w.r.t Alpha channel. > Number of drm properties are limited so should we restrain from adding this > as drm property or should we expose this as IOCTL itself. We need to stop adding properties on a whim and design and document them properly. So what I'd like to see is someone going over the current properties and collecting them up in some (even bares bones) documentation in Documentation/Docbook. The current way will lead to a huge mess when userspace actually starts to depend on properties. So far properties have been mostly some optional extra junk on the side people that may want to frob, but that's going to change as we add more of them, especially with plane and crtc properties, which actually affect how the scene gets composed together. And I think we need to put a hold on adding the plane properties to the crtc since the plan is to convert everything to drm_plane. With the current rate we're going to have a ton of properties on the crtc that no one will use. Adding properties to the sprite planes seems OK in the meantime. As far as alpha blending is concerned I've had the following ideas: - we need a plane property for constant alpha. Some drivers might already have this, so might be good to check. Although I'm fairly sure what's there won't be entirely future proof. I was thinking that we should standardize of using 16bits for color components in properties. That way you can still stick a full ARGB value into one property, and we should be good for a few more years until someone has the idea to move beyond 16bits per channel. And it's more or less hardware agnostic. Obviously if the hardware won't use the full precision, you get to throw away the low bits, but I don't think there's any other good way to go. - we need another property to indicate whether the source pixels are premultiplied or not. Or maybe it's easier for people to think in terms of what operations the hardware will do, in which case we should make the property indicate whether the hardware will do the premultiplication during blending or not. I'm not sure which approach feels more natural to people. - And finally we need to figure out how to blend it all together. It might make sense to model this after glBlendFunc(), so it would be an enum property, or maybe two if we want separate properties for source and destination factors. Obviously the final result will depend on additional things like the z-order, which is going to be another property. I think this one might already exists in some form in other drivers. So we should definitely look at what's there and try to do the same if possible. Which again underlines the need to collect up the current properties into some central documentation. -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
