On Mon, Sep 2, 2013 at 3:39 AM, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Fri, Aug 30, 2013 at 10:00:28AM -0400, Rob Clark wrote: >> On Thu, Aug 29, 2013 at 7:34 PM, Greg Hackmann <ghackmann@xxxxxxxxxx> wrote: >> > On Thu, Aug 29, 2013 at 5:54 AM, Rob Clark <robdclark@xxxxxxxxx> 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? If there is not also a case where you'd want userspace to be able to use the two CRTC's independently, then I guess we can hide it in kernel. Otherwise, it seems that would get a bit awkward. > 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 ... Yeah, that is the case today. But seems like we should be able to expose crtc/plane limits so that userspace can figure it out in a generic way. Note that nothing actually has to split up fb's, but just setup planes to scanout a single fb at the appropriate x/y offsets. > 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. yeah, I think understanding the hw better should help understand whether N CRTCs to one encoder, or N encoders to one connector, or ?? BR, -R > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
