From mboxrd@z Thu Jan 1 00:00:00 1970 From: Damien Lespiau Subject: Re: Stereo 3D v3 Date: Sun, 8 Sep 2013 16:03:52 +0100 Message-ID: <20130908150352.GB1175@strange.config> References: <1378493845-476-1-git-send-email-damien.lespiau@intel.com> <20130906191141.GC13167@nuc-i3427.alporthouse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTP id 6A402E62AC for ; Sun, 8 Sep 2013 08:04:11 -0700 (PDT) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: David Herrmann Cc: dri-devel List-Id: dri-devel@lists.freedesktop.org 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. -- Damien