linux-kernel - Re: [PATCH] media: venus: dec: Fix capture formats enumeration order

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] [day] [month] [year] [list]

Message-ID: <87bkkkoovx.fsf@minerva.mail-host-address-is-not-set>
Date:   Wed, 22 Mar 2023 15:13:22 +0100
From:   Javier Martinez Canillas <javierm@...hat.com>
To:     Jordan Crouse <jorcrous@...zon.com>,
        Enric Balletbo i Serra <eballetb@...hat.com>
Cc:     Dikshita Agarwal <quic_dikshita@...cinc.com>,
        linux-kernel@...r.kernel.org, Albert Esteve <aesteve@...hat.com>,
        Stanimir Varbanov <stanimir.varbanov@...aro.org>,
        Sergio Lopez <slp@...hat.com>, Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Stanimir Varbanov <stanimir.k.varbanov@...il.com>,
        Vikash Garodia <quic_vgarodia@...cinc.com>,
        linux-arm-msm@...r.kernel.org, linux-media@...r.kernel.org
Subject: Re: [PATCH] media: venus: dec: Fix capture formats enumeration order

Javier Martinez Canillas <javierm@...hat.com> writes:

Hello Stanimir and Dikshita,

> Jordan Crouse <jorcrous@...zon.com> writes:
>
>> On Tue, Mar 07, 2023 at 05:20:18PM +0100, Enric Balletbo i Serra wrote:
>
> [...]
>
>>> >
>>> > But regardless, I think that it would be better for a driver to
>>> > not change the order of advertised VIDIOC_ENUM_FMT pixel formats.
>>> >
>>> > Because what happens now is that a decoding that was previously
>>> > working by default is not working anymore due a combination of
>>> > the default being changed and S_FMT not working as expected.
>>
>> For my part, I was using the gstreamer v4l2 decoder which for some reason tries
>> to verify it can support whatever format it gets with G_FMT *before*
>> trying a S_FMT. I can't confirm or deny if S_FMT currently works or not.
>>
>> That said, I entirely agree with Javier. While it might be more
>> bandwidth efficient, QC08C is a obscure format. It is far more likely that the
>> average open source user would rather use a well known output format and, as
>> has been mentioned, once S_FMT is fixed those in the know can use the other
>> formats if they are working with other Qualcomm hardware blocks.
>>
>
> Agreed. The rule is that the kernel shouldn't regress user-space and the
> patches that changed the default format certainly did that. So from that
> point of view I think that this patch should land.
>
> There's also Enric's point that NV12 is a more common format and supported
> by more user-space programs. That's why think that regardless of the S_FMT
> situation, makes sense to revert to the previous default behaviour.
>

Any news on this patch? It would be great to fix this at least for v6.3.

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat