linux-kernel - Re: [RFC PATCH v6 02/11] media: v4l2: Extend pixel formats to unify single/multi-planar handling (and more)

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: <03f6fd9ff6a757f6d1cb6cc552efcb0b94327104.camel@ndufresne.ca>
Date:   Thu, 10 Nov 2022 12:06:59 -0500
From:   Nicolas Dufresne <nicolas@...fresne.ca>
To:     Hsia-Jun Li <Randy.Li@...aptics.com>,
        Helen Koike <helen.koike@...labora.com>
Cc:     mchehab@...nel.org, hans.verkuil@...co.com,
        laurent.pinchart@...asonboard.com, sakari.ailus@....fi,
        boris.brezillon@...labora.com, hiroh@...omium.org,
        Brian.Starkey@....com, kernel@...labora.com,
        narmstrong@...libre.com, linux-kernel@...r.kernel.org,
        frkoenig@...omium.org, stanimir.varbanov@...aro.org,
        tfiga@...omium.org, Hans Verkuil <hverkuil@...all.nl>,
        linux-media@...r.kernel.org
Subject: Re: [RFC PATCH v6 02/11] media: v4l2: Extend pixel formats to unify
 single/multi-planar handling (and more)

Le samedi 05 novembre 2022 à 23:19 +0800, Hsia-Jun Li a écrit :
> > > VIDIOC_ENUM_EXT_PIX_FMT would report NV12 and NV12M, while 
> > > VIDIOC_ENUM_FMT
> > > would just report NV12M.
> > 
> > If NV12 and NV12M are equivalent in Ext API, I don't see why we would
> > report both (unless I'm missing something, which is probably the case).
> > 
> > The idea was to deprecate the M-variants one day.
> I was thinking the way in DRM API is better, always assuming it would 
> always in a multiple planes. The only problem is we don't have a way to 
> let the allocator that allocate contiguous memory for planes when we 
> need to do that.

Its not too late to allow this to be negotiated, but I would move this out of
the pixel format definition to stop the explosion of duplicate pixel formats,
which is a nightmare to deal with. If I simplify the discussion, we want to
negotiate contiguity with the driver. The new FMT structure should have a
CONTIGUOUS flag. So if userpace sets:

  S_FMT(NV12, CONTIGUOUS)

The driver can accepts, and return the unmodified structure, or may drop the
CONTIGUOUS flag, which would mean its not supported. Could be the other way
around too. As for allocation, if you have CONTIGUOUS flag set, userspace does
not have to export or map memory for each planes, as they are the same. We
simply need to define the offset as relative to their allocation, which I think
is the most sensible thing.

Nicolas