From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [RFC 0/4] Atomic Display Framework Date: Mon, 2 Sep 2013 09:39:05 +0200 Message-ID: <20130902073905.GR9374@phenom.ffwll.local> References: <1377741081-30189-1-git-send-email-ghackmann@google.com> <20130829073630.GD11428@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by gabe.freedesktop.org (Postfix) with ESMTP id D02A7E6320 for ; Mon, 2 Sep 2013 00:38:51 -0700 (PDT) Received: by mail-ee0-f43.google.com with SMTP id e52so2157372eek.16 for ; Mon, 02 Sep 2013 00:38:51 -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: Rob Clark Cc: "linaro-mm-sig@lists.linaro.org" , "dri-devel@lists.freedesktop.org" , Erik Gilling List-Id: dri-devel@lists.freedesktop.org On Fri, Aug 30, 2013 at 10:00:28AM -0400, Rob Clark wrote: > On Thu, Aug 29, 2013 at 7:34 PM, Greg Hackmann wrote: > > On Thu, Aug 29, 2013 at 5:54 AM, Rob Clark wrote: > >> > >> I guess if you have multiple encoders + multiple connectors for the > >> "ganging" case, then it probably just looks like 2x displays, and > >> nothing more really needed? > >> > >> I'm a bit fuzzy on what the hw looks like in this "ganging" scenario, > >> so I'm not completely sure what the best approach is. But if we do > >> have hw like this, then it makes sense to support it *somehow* in KMS. > > > > > > I don't have the hardware anymore so this is all working from memory, it > > didn't look like two independent displays. You had to explicitly set up > > connections between the two mixers to deal with things like scaled overlays > > that spanned both mixers (there was some in-hardware magic to make sure > > there wasn't a visible seam where the two mixers met). > > Ok, sounds like mixer == crtc (ie. the thing the combines one or more > planes)? So it sounds maybe a bit like: > > plane0_0 -\ > ... +---> CRTC -\ > plane0_n -/ | > +--> encoder -> connector > plane1_0 -\ | > ... +---> CRTC -/ > plane1_n -/ More than one crtc to the same encoder feels funny. Can't we just keep this mixer thing internal to the kms driver by making the failure conditions a bit more obtuse to userspace? Either way we need highly special userspace to get this thing going, since a generic modesetting driver probably can't figure out that it needs to split up the logical framebuffer into smaller planes to be able to actually shovel all the pixels to the screen. Thus far the assumption we've backed into all dumb kms drivers is that the crtc/plane limit is also the limit for the maximum output resolution ... Could we have a notch more details on how this is exactly wired up? Another approach would be a set of encoders for each part of the display and some metadata (like left/right-of, ...) so that userspace understands how the aggregate display is stitched togeter. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch