Stereo 3D v3

Chris Wilson chris at
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 mailing list