Re: [RFC v2 0/5] Common Display Framework

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Daniel,

On Tuesday 18 December 2012 09:30:00 Daniel Vetter wrote:
> On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark <rob.clark@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.

I totally agree. As explained in my replies to Dave and Rob, I don't want to 
share devices between the different subsystems at runtime, but I'd like to 
avoid writing two drivers for a single device that can be used for display and 
graphics on one board, and video output on another board (HDMI transmitters 
are a good example).

-- 
Regards,

Laurent Pinchart