Hi On Sun, Sep 8, 2013 at 1:59 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Fri, Sep 6, 2013 at 9:11 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
