linux-kernel - Re: [PATCH v7 2/4] media: videodev2: add V4L2_FMT_FLAG_FIXED

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]

Date:   Tue, 11 Jun 2019 20:58:32 -0400
From:   Nicolas Dufresne <nicolas@...fresne.ca>
To:     Philipp Zabel <p.zabel@...gutronix.de>,
        Hans Verkuil <hverkuil@...all.nl>,
        Maxime Jourdan <mjourdan@...libre.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Hans Verkuil <hans.verkuil@...co.com>
Cc:     Kevin Hilman <khilman@...libre.com>,
        Jerome Brunet <jbrunet@...libre.com>,
        Neil Armstrong <narmstrong@...libre.com>,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-amlogic@...ts.infradead.org
Subject: Re: [PATCH v7 2/4] media: videodev2: add
 V4L2_FMT_FLAG_FIXED_RESOLUTION

Le mardi 11 juin 2019 à 10:52 +0200, Philipp Zabel a écrit :
> On Wed, 2019-06-05 at 15:39 +0200, Hans Verkuil wrote:
> > Hi Maxime,
> > 
> > I am wondering if this flag shouldn't be inverted: you set
> > V4L2_FMT_FLAG_DYN_RESOLUTION if dynamic resolution is supported,
> > otherwise it isn't.
> > 
> > Can all the existing mainlined codec drivers handle midstream
> > resolution changes?
> > 
> > s5p-mfc, venus and mediatek can, but I see no SOURCE_CHANGE event in
> > the coda drivers, so I suspect that that can't handle this.
> > 
> > Philipp, what is the status of the coda driver for dynamic resolution
> > changes?
> 
> FTR, to my knowledge there is no dynamic resolution change support in
> the firmware, as there is no signal (interrupt nor picture run return
> value) to indicate that different headers were parsed.
> 
> I am planning to add the initial source change event required by the
> current decoder API documentation, but I am afraid there will be no
> support for source changes due to mid-stream resolution changes due to
> firmware limitations.

I'm far from familiar with this IP, but at least on CODA988, I can read
from the manual that the workflow is to first guess the allocation, and
if you guess it wrong, an error is returned. What seems to match the
SOURCE_CHANGE event in that version would be in the picture status
register, the bit 20, which is documented as triggered if the stream
requires bigger buffers sizes, or more buffers. After fixing that, you
should, if I read correctly, retry.

It does not notify if the buffers are too large, but you can detect,
since there is register with the output stream information. This
basically means that for V4L2 restriction, you'd have to bounce the
buffers on frame size boundary or something like thisé

This workflow is very similar to how OMX works, but V4L2 is even less
flexible on allocation vs format, forcing more re-allocation.

> 
> regards
> Philipp