On Fri, Feb 21, 2014 at 9:49 AM, Rob Clark <robdclark at gmail.com> wrote: > On Fri, Feb 21, 2014 at 9:20 AM, Sharma, Shashank > <shashank.sharma at intel.com> 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.
