linux-kernel - Re: [PATCH v1] media: videobuf2: Allow applications customize data offsets of capture buffers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f80128c50d3dacff0af70bd88521abae42476f85.camel@ndufresne.ca>
Date:   Fri, 25 Mar 2022 08:32:01 -0400
From:   Nicolas Dufresne <nicolas@...fresne.ca>
To:     Dmitry Osipenko <dmitry.osipenko@...labora.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Tomasz Figa <tfiga@...omium.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Hans Verkuil <hverkuil-cisco@...all.nl>,
        Benjamin Gaignard <benjamin.gaignard@...labora.com>,
        Andrzej Pietrasiewicz <andrzej.p@...labora.com>,
        Gustavo Padovan <gustavo.padovan@...labora.com>,
        Boris Brezillon <bbrezillon@...labora.com>,
        Daniel Almeida <daniel.almeida@...labora.com>,
        Sebastian Fricke <sebastian.fricke@...labora.com>,
        Laura Nao <laura.nao@...labora.com>
Cc:     linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
        Dmitry Osipenko <digetx@...il.com>
Subject: Re: [PATCH v1] media: videobuf2: Allow applications customize data
 offsets of capture buffers

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).

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