On Mon, Sep 2, 2013 at 3:39 AM, Daniel Vetter daniel@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 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?
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