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 -/
So I wonder if we should just add the x,y,w,h output parameters to crtc. That could also be used to specify borders in the normal one crtc per encoder case. Although the border color is then a bit a question mark. Supposedly the crtc can have its own background color, but i guess the border color need not match that necessarily. So maybe add an encoder bg color property too (or maybe just slap it to the connector since we don't currently have encoder properties).
Another related thing I really want to expose is the crtc input size (ie. the coordinate space that the planes' output coordinates live in). That way the user will get explicit control over the scaler in the crtc (panel fitter in i915 lingo).