linux-kernel - Re: [PATCH v6 2/2] [media] s5p-mfc: Handle 'v4l2_pix_format:field' in try_fmt and g

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: <1488381666.14858.5.camel@collabora.com>
Date:   Wed, 01 Mar 2017 10:21:06 -0500
From:   Nicolas Dufresne <nicolas.dufresne@...labora.com>
To:     Andrzej Hajda <a.hajda@...sung.com>,
        Thibault Saunier <thibault.saunier@....samsung.com>,
        linux-kernel@...r.kernel.org
Cc:     Mauro Carvalho Chehab <mchehab@...nel.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Kukjin Kim <kgene@...nel.org>,
        Mauro Carvalho Chehab <mchehab@...pensource.com>,
        Andi Shyti <andi.shyti@...sung.com>,
        linux-media@...r.kernel.org, Shuah Khan <shuahkh@....samsung.com>,
        Javier Martinez Canillas <javier@....samsung.com>,
        linux-samsung-soc@...r.kernel.org,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Inki Dae <inki.dae@...sung.com>,
        Sylwester Nawrocki <s.nawrocki@...sung.com>,
        linux-arm-kernel@...ts.infradead.org,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Jeongtae Park <jtp.park@...sung.com>,
        Kyungmin Park <kyungmin.park@...sung.com>,
        Kamil Debski <kamil@...as.org>
Subject: Re: [PATCH v6 2/2] [media] s5p-mfc: Handle 'v4l2_pix_format:field'
 in try_fmt and g_fmt

Le mercredi 01 mars 2017 à 14:12 +0100, Andrzej Hajda a écrit :
> - on output side you have encoded bytestream - you cannot say about
> interlacing in such case, so the only valid value is NONE,
> - on capture side you have decoded frames, and in this case it
> depends
> on the device and driver capabilities, if the driver/device does not
> support (de-)interlacing (I suppose this is MFC case), interlace type
> field should be filled according to decoded bytestream header (on
> output
> side), but no direct copying from output side!!!

I think we need some nuance here for this to actually be usable. If the
information is not provided by the driver (yes, hardware is limiting
sometimes), it would make sense to copy over the information that
userspace provided. Setting NONE is just the worst approximation in my
opinion.

About MFC, it will be worth trying to read the DISPLAY_STATUS after the
headers has been processed. It's not clearly stated in the spec if this
will be set or not.

Nicolas
Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)