[RFC 0/4] Atomic Display Framework

[Rob Clark]

On Mon, Sep 2, 2013 at 3:39 AM, Daniel Vetter <daniel at 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 at google.com> wrote:
>> > On Thu, Aug 29, 2013 at 5:54 AM, Rob Clark <robdclark at 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