On Sun, Sep 08, 2013 at 04:03:52PM +0100, Damien Lespiau wrote: > On Sun, Sep 08, 2013 at 03:46:43PM +0200, David Herrmann wrote: > > The series implements SET_CAP as a per _file_ capability set, not per > > master. I like it this way. Note that with SET_VERSION, we already > > have a per _master_ capability set. Compared to SET_CAP it only allows > > incremental capability changes, but that's fine I think. > > > > However, the problem with per-master capabilities (SET_VERSION) is > > that we currently have no way to control which master a > > graphics-server gets assigned to. If it's started in background, it > > will get the same master as the foreground compositor. Therefore, we > > don't want per-master client-capabilities. It's wrong and breaks > > existing setups (same as SET_VERSION, and everyone knows that). I also > > don't see a reason to bind capabilities to a master object. > > > > SET_CAP describes what the *calling client* understands and can work > > with. And this is logically bound to drm_file (as it represents a > > client). On the other hand, GET_CAP describes what the *device* > > understands and provides. This is obviously bound to a "drm_device". A > > "drm_master" object allows to split GET_CAP capabilities and resources > > across multiple logical master objects. But these resemble a > > drm_device much more than a drm_file. > > > > So no, this capability is not dropped with a change in master. It's > > independent of the active/bound master. It just describes what a > > client sees or not sees. > > Right, that sums it up. Note that while I've made stereo_allowed a per > fd thing (which is what I wanted in that case, alter the reality viewed > by the process opening the file), SET_CAP itself it marked as master > only. This can be changed in the future to provide per-cap access > restrictions if needed. This could be renamed to SET_CLIENT_CAP and also drop the master requirement. (That some capabilities only affect master ioctls is irrelevant I think, as the client will be master at that time.) That would reduce the confusion between the device caps and the session caps. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
