[RFC v2 0/5] Common Display Framework

[Daniel Vetter]

On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark <rob.clark at linaro.org> wrote:
>> The other thing I'd like you guys to do is kill the idea of fbdev and
>> v4l drivers that are "shared" with the drm codebase, really just
>> implement fbdev and v4l on top of the drm layer, some people might
>> think this is some sort of maintainer thing, but really nothing else
>> makes sense, and having these shared display frameworks just to avoid
>> having using drm/kms drivers seems totally pointless. Fix the drm
>> fbdev emulation if an fbdev interface is needed. But creating a fourth
>> framework because our previous 3 frameworks didn't work out doesn't
>> seem like a situation I want to get behind too much.
>
> yeah, let's not have multiple frameworks to do the same thing.. For
> fbdev, it is pretty clear that it is a dead end.  For v4l2
> (subdev+mcf), it is perhaps bit more flexible when it comes to random
> arbitrary hw pipelines than kms.  But to take advantage of that, your
> userspace isn't going to be portable anyways, so you might as well use
> driver specific properties/ioctls.  But I tend to think that is more
> useful for cameras.  And from userspace perspective, kms planes are
> less painful to use for output than v4l2, so lets stick to drm/kms for
> output (and not try to add camera/capture support to kms).. k, thx

Yeah, I guess having a v4l device also exported by the same driver
that exports the drm interface might make sense in some cases. But in
many cases I think the video part is just an independent IP block and
shuffling data around with dma-buf is all we really need. So yeah, I
guess sharing display resources between v4l and drm kms driver should
be a last resort option, since coordination (especially if it's
supposed to be somewhat dynamic) will be extremely hairy.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch