[RFC 0/2] New feature: Framebuffer processors

Daniel Vetter daniel at ffwll.ch
Wed Aug 24 11:57:11 UTC 2016


On Wed, Aug 24, 2016 at 08:44:24PM +0900, Inki Dae wrote:
> Hi,
> 
> 2016년 08월 23일 18:41에 Daniel Stone 이(가) 쓴 글:
> > Hi,
> > 
> > On 22 August 2016 at 16:23, Rob Clark <robdclark at gmail.com> wrote:
> >> I guess a lot comes down to 'how long before hw designers bolt a CP to
> >> the thing'..  at that point, I think you especially don't want a
> >> per-blit kernel interface.
> > 
> > Regardless of whether or not we want it, we already _have_ it, in the
> > form of V4L2 M2M. There are already a few IP blocks working on that, I
> > believe. If V4L2 <-> KMS interop is painful, well, we need to fix that
> > anyway ...
> 
> So we are trying this. We had expereneced using V4L2 and DRM together on
> Linux Platform makes it too complicated, and also integrated DRM with
> M2M such as 2D and Post processor makes it simplified.  So We have been
> trying to move existing V4L2 based drivers into DRM excepting HW Video
> Codec - called it MFC - and Camera sensor and relevant things.
> I think now V4L2 and DRM frameworks may make many engineers confusing
> because there are the same devices which can be controlled by V4L2 and
> DRM frameworks - maybe we would need more efforts like Laurent did with
> Live source[1] in the future.

Can you pls explain in more detail where working with both v4l and drm
drivers and making them cooperate using dma-bufs poses problems? We should
definitely fix that.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the dri-devel mailing list