On Mon, May 12, 2014 at 05:35:13PM +0530, Sharma, Shashank wrote: > Thanks for your time and the comments David. > please find mine inline. > > Regards > Shashank > On 5/12/2014 5:20 PM, David Herrmann wrote: > >Hi > > > >On Mon, May 12, 2014 at 12:26 PM, Sharma, Shashank > ><shashank.sharma@xxxxxxxxx> wrote: > >>Benefits of using color manager: > >>================================ > >>1. Unique framework for all the color correction properties, across all > >> DRM drivers, across various platforms. > >>2. Only one set/get call for all kind of properties using the common > >>protocol. One get call can tell what are the color correction capabilities > >>of the SOC, registered by driver. > > > >What's the advantage of that? We should add a > >DRM_MODE_OBJ_SET_PROPERTIES call if we want to accelerate things, > >instead of adding huge payloads. > > > The problem here is a DRM_OBJECT_MODE_SET_PROPERTIES call can pass limited > value. But there are few properties like gamma correction which need a full > LUT(256 vals) to be passed according to the correction values. The plan here > is pretty much aligned to your suggestion, ie to use > DRM_OBJECT_MODE_SET_BLOB kind of property, and extract the data from the > blob based on a protocol. > Why do you think its a huge payload ? Gamma correction lut is already supported. For the other stuff we can use SET_BLOB (or fix it if it doesn't work). > >I really think we should define one property for each color-correction > >interface. I cannot see any downside of that except that we should add > >DRM_MODE_OBJ_SET_PROPERTIES. > > As I was discussing, if there are 10 color correction properties a SOC > supports, we have to create 10 properties which doesn't look good, when all > the properties will do the same (set/reset few registers as correction). We > already have a case where we expose 6 different type of corrections. > > One more benefit is, this part is centrally controlled, so you can always > know what's the state of color correction in single shot at any time. This > will also provide us to do a lot of common things to do at the same place, > like floating point arithmetic to register value conversion in a supporting > userspace library, which might be required for many cases. > > INHO, its always good to have a controlled interface/ framework to have > similar things aligned to. Those are all just reasons for atomic modeset and maybe an atomic modeget ioctl which transfers the entire blob of things. Maybe we should start with the atomic modeget to get things rolling. Otoh you can always do that in userspace since we assume there's only one display manager. And we absolutely want color correction to be part of the atomic modeset stuff (since some hw has e.g. per-plane gamma correction). So adding a new way to set them despite that the current atomic modeset proposal is fully centered on properties and that we've added all these properties for just this reasons is important. I still don't see what you can do with the color manager that's impossible to do with properties. And having a large pile of properties imo doesn't count as a good reason, since with the color manager you still have all these settings. But maybe just encoded differently, e.g. in a bitfield or something. Changing the way you set stuff doesn't fundamentally change things at all. And for modeset we can throw efficiency of the marshalling/de-marshalling over board (within some limits of course) since we do about 60*num_pipes modeset/pageflip calls per second at most. And the overhead of the encoding/decoding of the properties will be completely washed out by all the register i/o we need to do to UC pci bars. > But afaik that's already the plan for > >atomic-modesetting, right? > > > >Thanks > >David > > > AFAIK color management is not a part of atomic modeset, but once we create > such an interface, it would be really easy to club that in the atomic > modeset. See above, this is a reason to _not_ add a separate color manager. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
