[RFC v2 0/5] Common Display Framework

[Rob Clark]

On Wed, Dec 19, 2012 at 9:37 AM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
> On 2012-12-19 17:26, Rob Clark wrote:
>>
>> And, there are also external HDMI encoders (for example connected over
>> i2c) that can also be shared between boards.  So I think there will be
>> a number of cases where CDF is appropriate for HDMI drivers.  Although
>> trying to keep this all independent of DRM (as opposed to just
>> something similar to what drivers/gpu/i2c is today) seems a bit
>> overkill for me.  Being able to use the helpers in drm and avoiding an
>> extra layer of translation seems like the better option to me.  So my
>> vote would be drivers/gpu/cdf.
>
> Well, we need to think about that. I would like to keep CDF independent
> of DRM. I don't like tying different components/frameworks together if
> there's no real need for that.
>
> Also, something that Laurent mentioned in our face-to-face discussions:
> Some IPs/chips can be used for other purposes than with DRM.
>
> He had an example of a board, that (if I understood right) gets video
> signal from somewhere outside the board, processes the signal with some
> IPs/chips, and then outputs the signal. So there's no framebuffer, and
> the image is not stored anywhere. I think the framework used in these
> cases is always v4l2.
>
> The IPs/chips in the above model may be the exact same IPs/chips that
> are used with "normal" display. If the CDF was tied to DRM, using the
> same drivers for normal and these streaming cases would probably not be
> possible.

Well, maybe there is a way, but it really seems to be
over-complicating things unnecessarily to keep CDF independent of
DRM..  there will be a lot more traditional uses of CDF compared to
one crazy use-case.  So I don't really fancy making it more difficult
than in needs to be for everyone.

Probably the thing to do is take a step back and reconsider that one
crazy use-case.  For example, KMS doesn't enforce that the buffer
handled passed when you create a drm framebuffer object to scan out is
a GEM buffer.  So on that one crazy platform, maybe it makes sense to
have a DRM/KMS display driver that takes a handle to identify which
video stream coming from the capture end of the pipeline.  Anyways,
that is just an off-the-top-of-my-head idea, probably there are other
options too.

BR,
-R

>  Tomi
>
>