lkml.org 
[lkml]   [2022]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v1] media: videobuf2: Allow applications customize data offsets of capture buffers
From


On 3/25/22 13:32, Nicolas Dufresne wrote:
> Le jeudi 24 mars 2022 à 21:20 +0300, Dmitry Osipenko a écrit :
>> The root of the problem is that DRM UAPI is more flexible and allows to
>> customize offsets for both S/MPLANEs, while V4L doesn't allow to do it
>> at all. I'm exploring all the potential options, so far neither of the
>> proposed variants is ideal.
>
> In GStreamer kmssink, the way DRM is used, is that if you have 2 planes in your
> pixel format, but only received 1 DMABuf, we will pass this DMABuf twice (well
> GEM handles, but twice), with appropriate offset.
>
> With this in mind, the idea for V4L2 could be to always resort to MPLANE for
> this purpose. The tricky part for userland is that it needs to know the dual
> pixel format and map that accordingly. That is a bit difficult and this is
> something Helen was trying to address with the v4l2_buffer_ext (that and
> allowing space to store DRM Modifiers in the future).

FYI: here is Helen's last patch series. Since Helen is no longer active in
the media subsystem, someone else who is sufficiently motivated would have to
take over.

https://patchwork.linuxtv.org/project/linux-media/cover/20210114180738.1758707-1-helen.koike@collabora.com/

I'm not enthusiastic about messing with data_offset: it was - in hindsight - a
bad idea.

Regards,

Hans

>
> The second challenge is the overhead. In DRM, as we "prime" the DMABuf into
> handles, this gives a kernel object to store any relevant information about the
> buffer. So having it duplicate can be done at no cost. In V4L2, the driver would
> need to handle that more often. Specially that despite the recommendation
> (except for primary buffer decoder, were this is mandatory), we don't force a
> strict DMABuf / Buffer IDX mapping.
>
> Nicolas

\
 
 \ /
  Last update: 2022-05-18 12:29    [W:0.154 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site