From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Pinchart Date: Mon, 24 Dec 2012 13:39:02 +0000 Subject: Re: [RFC v2 0/5] Common Display Framework Message-Id: <2197335.PVFVBmr4Hc@avalon> List-Id: References: <1353620736-6517-1-git-send-email-laurent.pinchart@ideasonboard.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Daniel Vetter Cc: Rob Clark , Dave Airlie , Thomas Petazzoni , Linux Fbdev development list , Benjamin Gaignard , Tom Gall , Kyungmin Park , "dri-devel@lists.freedesktop.org" , Ragesh Radhakrishnan , Tomi Valkeinen , Philipp Zabel , Bryan Wu , Maxime Ripard , Vikas Sajjan , Sumit Semwal , Sebastien Guiriec , "linux-media@vger.kernel.org" Hi Daniel, On Tuesday 18 December 2012 09:30:00 Daniel Vetter wrote: > On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark 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