On Fri, Feb 21, 2014 at 9:20 AM, Sharma, Shashank <shashank.sharma@xxxxxxxxx> 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). 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. _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
