On Mon, Sep 2, 2013 at 9:19 AM, Rob Clark <robdcl...@gmail.com> wrote:
> On Mon, Sep 2, 2013 at 3:39 AM, Daniel Vetter <dan...@ffwll.ch> 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 <ghackm...@google.com> wrote:
>>> > On Thu, Aug 29, 2013 at 5:54 AM, Rob Clark <robdcl...@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?
>
> 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 ??
On our hardware there is basically a crossbar between the crtcs and
the encoders:
GRPH -\
+---> CRTC -|
OVL -/ |
+--> encoder -> connector
GRPH -\ |
+---> CRTC -|
OVL -/ |
+--> encoder -> connector
GRPH -\ |
+---> CRTC -|
OVL -/ |
+--> encoder -> connector
GRPH -\ |
+---> CRTC -|
OVL -/
Encoders are hardcoded to connectors, planes (GRPH and OVL) are
hardcoded to crtcs, but crtcs can be routed between encoders. There
are also cases where you can gang crtcs (e.g., map multiple crtcs to a
single encoder) for handling certain corner cases.
Alex
>
> 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@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
