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@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
