From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH 10/12] drm: Don't allow multiple buffers fb with stereo modes Date: Tue, 17 Sep 2013 14:02:34 +0300 Message-ID: <20130917110234.GT4531@intel.com> References: <1379353735-4472-1-git-send-email-damien.lespiau@intel.com> <1379353735-4472-11-git-send-email-damien.lespiau@intel.com> <20130917082046.GP4531@intel.com> <20130917090312.GG29268@strange.amr.corp.intel.com> <20130917095409.GR4531@intel.com> <20130917103748.GM32145@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: <20130917103748.GM32145@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Daniel Vetter Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Tue, Sep 17, 2013 at 12:37:48PM +0200, Daniel Vetter wrote: > On Tue, Sep 17, 2013 at 12:54:09PM +0300, Ville Syrj=E4l=E4 wrote: > > On Tue, Sep 17, 2013 at 10:03:12AM +0100, Damien Lespiau wrote: > > > On Tue, Sep 17, 2013 at 11:20:46AM +0300, Ville Syrj=E4l=E4 wrote: > > > > +++ b/drivers/gpu/drm/drm_crtc.c > > > > > @@ -2131,6 +2131,17 @@ int drm_mode_setcrtc(struct drm_device *de= v, void *data, > > > > > goto out; > > > > > } > > > > > = > > > > > + /* > > > > > + * Do not allow the use of framebuffers consisting of multiple > > > > > + * buffers with stereo modes until all the details API details > > > > > + * are fleshed out (eg. interaction with drm_planes, switch > > > > > + * between a 1 buffers and a 2 buffers fb, ...) > > > > > + */ > > > > > + if (fb->num_buffers > 1 && drm_mode_is_stereo(mode)) { > > > > > + ret =3D -EINVAL; > > > > > + goto out; > > > > > + } > > > > = > > > > This would prevent planar buffers in stereo modes. I'm think we just > > > > ignore the matter for now and let drivers deal with it. We don't ha= ve > > > > enough handles anyway for planar stereo, so maybe we even want to a= dd > > > > separate left/right fb attachment properties to the planes instead = of > > > > tying it up in inside a single fb. Or we cook up addfb3 when we hit > > > > this problem for real. I think we'd anyway need some kind of flag f= or > > > > the fb if it contains both left and right buffers. > > > = > > > I'm quite happy to ignore 3 planes YUV stereo fbs for now :) (2 planes > > > YUV stereo fbs still fit!). > > > = > > > Are you fine with this test though, or do you mean ignore the whole > > > matter of forbidding this case (or just the multiplane stereo fb case= )? > > > I was just thinking that I missed the addition of this check in the p= age > > > flip ioctl. > > = > > Yeah, I was thinking we that we can ignore this issue for now, and so we > > wouldn't need the check. Currently for non-stereo cases the only thing > > we check is that there is a valid handle for each plane. If userspace > > passes more handles, we simply ignore the extra ones. > = > I guess we should start to check that. For 3d framebuffers with 2 > separate buffer handles for each plane I think we need to add another flag > to addfb2, e.g. > = > #define DRM_MODE_FB_3D_2_FRAMES (1<<1) /* separate left/right buffers, do= ubles plane count */ > = > and then also throw in the respective check code into the core that > userspace supplies sufficient amounts of buffers in framebuffer_check() > by adjusting drM_format_num_planes and drm_format_plane_cpp. Well, we shouldn't mix the plane vs. buffers/handles/whatever concepts. The number of planes is clearly defined by the pixel format. But yes, we should probably add a drm_format_num_buffers() function to figure out how many buf= fers are required. But the problem is that addfb2 can't supply more than 4. So we need a new ioctl if we want to collect all that information inside a single drm_fb object. If we do add another ioctl then I think we should go at least to 16, since we might also want to have separate buffers for each field in interlaced framebuffers. And then we need to clearly define which handle is which plane/field/eye. Something like this for example: eye=3Dleft field=3Dtop plane=3D0 [plane=3D1 ...] [field=3Dbottom plane=3D0 = [plane=3D1 ...]] [eye=3Dright field=3Dtop plane=3D0 [plane=3D1 ...] [field=3Dbottom plane= =3D0 [plane=3D1 ...]]] so you first have all the planes for left/top, then all planes for left/bottom, then right/top, and finally right/bottom. -- = Ville Syrj=E4l=E4 Intel OTC