Hi
On Sun, Sep 8, 2013 at 1:59 PM, Daniel Vetter daniel@ffwll.ch wrote:
On Fri, Sep 6, 2013 at 9:11 PM, Chris Wilson chris@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