From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Paul Subject: Re: [PATCH 0/6] Intel Color Manager Framework Date: Fri, 21 Feb 2014 13:24:30 -0500 Message-ID: References: <1392899847-2641-1-git-send-email-shashank.sharma@intel.com> <20140220131129.GG3852@intel.com> <20140221091706.GJ3852@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org To: Rob Clark Cc: "intel-gfx@lists.freedesktop.org" , "dri-devel@lists.freedesktop.org" , "Shankar, Uma" , Rahul Sharma List-Id: dri-devel@lists.freedesktop.org On Fri, Feb 21, 2014 at 9:49 AM, Rob Clark wrote: > On Fri, Feb 21, 2014 at 9:20 AM, Sharma, Shashank > wrote: >> Hi Ville, >> >> Thanks for your time and comments. >> I can understand two basic problems what you see in this implementation: >> >> 1. The most important issue from my POV is that it can't be part of the atomic modeset. >> 2. it make the whole API inconsistent. >> >> I am not sure if its good to block all current implementation because we have thought something for this in atomic modeset. >> I think even in atomic modeset we need the core implementation like this, but the interface would be different, which might come in from of a DRM property. >> So at that time we can use this core implementation as it is, only the interfaces/framework needs to be changed. > > What I would suggest is re-form the userspace facing API to be > properties.. if needed we can add a setblobprop ioctl (Sean Paul was, > I think, adding that already). This is news to me ;-) I'm pulling the atomic stuff into the CrOS tree, but I think Rahul Sharma is the guy you're looking for wrt setblobprop (http://www.spinics.net/lists/dri-devel/msg54010.html). Sean > Then userspace and use setprop ioctls > for now, and optionally atomic ioctl later when it is in place. No > reason for it to be blocked waiting for atomic. > > btw, I didn't look into the patches yet, but full-nak on idea of > exposing via sysfs. This should be the sort of thing that is set by > the process that has mastership on the drm device, which we can't > enforce via sysfs. Using properties seems like the way to go. > > BR, > -R > >> In this way we can always go ahead with a current implementation, and can just change the interfaces to fit in to the final interface like DRM property in atomic modeset. >> Or you can suggest us the expected interface, and we can work on modifying that as per expectation.