Stereo 3D v3
chris at chris-wilson.co.uk
Tue Sep 10 07:14:52 PDT 2013
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
Chris Wilson, Intel Open Source Technology Centre
More information about the dri-devel