Stereo 3D v3

Daniel Vetter daniel at
Sun Sep 8 13:05:23 PDT 2013

On Sun, Sep 8, 2013 at 5:03 PM, Damien Lespiau <damien.lespiau at> 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.

Ok, I admit defaut, master doesn't make sense here ;-)

Cheers, Daniel
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 -

More information about the dri-devel mailing list