crtc ganging in KMS, "large" displays, etc

[Rob Clark]

On Tue, Apr 1, 2014 at 9:40 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
> 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.

right, things like 'STATUS' property for returning per-object status
would start as driver custom.  (And even 'SLAVE_CRTC'..)  Userspace
could look for certain property names in the same way that it looks
for certain gl extension strings.  But should be semi-standardized, so
other drivers which need the same thing should use same property
names/values/behaviors as much as possible.. which was the point for
starting the thread ;-)

BR,
-R


> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch