crtc ganging in KMS, "large" displays, etc

[Daniel Vetter]

On Tue, Apr 01, 2014 at 08:40:54AM -0400, Rob Clark wrote:
> No, not really.  I was just trying to get away with pushing some
> complexity (for case #1) up to userspace instead of doing it in the
> kernel.

To clarify: I don't think it makes sense to fully abstract this away in
the kernel, especially if userspace needs to be aware of the boundary
between the crtcs so that it can correctly tile up the logical frambuffer.
But I'm not sure whether trying to make that possible with a generic
userspace driver is sensible, or whether having a bit of magic glue code
in the ddx/wayland/hwc part for e.g. msm is the better option, at least in
the short term.

Since if the set of useable planes actually changes we need to push that
decision up the stack even further like wayland/hwc currently allow, and
maybe there's some things we need to fix at that layer first. Once we've
learned that lesson we can push things down again and add a neat little
generic kernel interface. At least thus far we've always done a bit of
prototyping with driver-specific code to learn a few lessons, e.g. the
various pieces of non-standard plane/overlay in i915.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch