Stereo 3D v3

[David Herrmann]

Hi

On Sun, Sep 8, 2013 at 1:59 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Fri, Sep 6, 2013 at 9:11 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
>> On Fri, Sep 06, 2013 at 07:57:16PM +0100, Damien Lespiau wrote:
>>> Follow up of:
>>>  http://lists.freedesktop.org/archives/dri-devel/2012-September/028278.html
>>>
>>> Let's try again! This time, intead of a magic connector property to select if
>>> we want to return more modeinfo flags to userspace, this series introduces a
>>> new SET_CAP ioctl.
>>>
>>> So the flow goes as following:
>>>   1/ the DRM client (limited to the DRM master) can notify it knows about those
>>>      flags through SET_CAP
>>
>> Is this capability dropped along with a change in master then?
>
> Yeah, I think it would make sense to store this flag in the master
> structure. But David Herrmann has some big plans for the drm master
> stuff, so would be good to have his opinion on this. David?

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.

Regarding my drm_master plans: I don't plan on changing the concept, I
just plan on adding ioctls to control master objects and allow
*multiple* active masters per device, but each with different
resources.
Just as a hint: with the current setup, we only have one master.
Seriously, add debug-prints to drm_master_create() and watch. The
problem is, chances are pretty low that a compositors starts while no
master is active. At least on my system.. here all compositors share a
master-object.

Comments?
David