Re: [RFC 0/4] Atomic Display Framework

[Daniel Vetter <daniel@ffwll.ch>]

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@google.com> wrote:
> > On Thu, Aug 29, 2013 at 5:54 AM, Rob Clark <robdclark@gmail.com> 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