From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: crtc ganging in KMS, "large" displays, etc Date: Tue, 1 Apr 2014 17:42:42 +0300 Message-ID: <20140401144242.GI21652@intel.com> References: <20140401080425.GH22327@phenom.ffwll.local> <20140401134055.GK22327@phenom.ffwll.local> <20140401141216.GH21652@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTP id 088A76E0A7 for ; Tue, 1 Apr 2014 07:44:58 -0700 (PDT) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Rob Clark Cc: "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org On Tue, Apr 01, 2014 at 10:22:07AM -0400, Rob Clark wrote: > On Tue, Apr 1, 2014 at 10:12 AM, Ville Syrj=E4l=E4 > wrote: > > On Tue, Apr 01, 2014 at 09:54:40AM -0400, Rob Clark wrote: > >> On Tue, Apr 1, 2014 at 9:40 AM, Daniel Vetter wrote: > >> > On Tue, Apr 01, 2014 at 08:40:54AM -0400, Rob Clark wrote: > >> >> No, not really. I was just trying to get away with pushing some > >> >> complexity (for case #1) up to userspace instead of doing it in the > >> >> kernel. > >> > > >> > To clarify: I don't think it makes sense to fully abstract this away= in > >> > the kernel, especially if userspace needs to be aware of the boundary > >> > between the crtcs so that it can correctly tile up the logical framb= uffer. > >> > But I'm not sure whether trying to make that possible with a generic > >> > userspace driver is sensible, or whether having a bit of magic glue = code > >> > in the ddx/wayland/hwc part for e.g. msm is the better option, at le= ast in > >> > the short term. > >> > > >> > Since if the set of useable planes actually changes we need to push = that > >> > decision up the stack even further like wayland/hwc currently allow,= and > >> > maybe there's some things we need to fix at that layer first. Once w= e've > >> > learned that lesson we can push things down again and add a neat lit= tle > >> > generic kernel interface. At least thus far we've always done a bit = of > >> > prototyping with driver-specific code to learn a few lessons, e.g. t= he > >> > various pieces of non-standard plane/overlay in i915. > >> > >> right, things like 'STATUS' property for returning per-object status > >> would start as driver custom. (And even 'SLAVE_CRTC'..) Userspace > >> could look for certain property names in the same way that it looks > >> for certain gl extension strings. But should be semi-standardized, so > >> other drivers which need the same thing should use same property > >> names/values/behaviors as much as possible.. which was the point for > >> starting the thread ;-) > > > > What's the problem with just using two crtcs? With the atomic API you > > just shovel the state for both down into the driver in one ioctl. This > > is pretty much what we'll need to do to drive those 4k MST DP displays > > as well. The driver will then have to do its best to genlock the crtcs > > if the hardware doesn't do it fully. IIRC that's how we're going to have > > to do the MST stuff, ie. use the same clock source for both obviously, > > and try to start all the pipes as fast as possible so that the vblanks > > line up. And that's going to require more changes to our modesetting > > codepaths. > = > well, two problems: > 1) it won't actually work (at least not without some overhaul of kms > core and helpers).. encoder only has a single crtc ptr. And anyway, > it is useful for the driver to differentiate between which pipe/mixer > is primary and which is slave. What does primary/slave mean here? That seems like a rather hardware specific notion. > The SLAVE_CRTC property essentially gives you that 2nd pointer you need. Would seem easier to add the pointer. Or even better: just expose the display as two connectors and then you don't have to change anything. It's just like having multiple displays positioned next to each other today. > 2) still would be nice to be able to drive 4k displays from x11.. and > for the most part there isn't much compelling reason for most ddx's to > migrate to atomic ioctl. Someone might argue that 4k support is a compelling reason ;) -- = Ville Syrj=E4l=E4 Intel OTC