linux-kernel - Re: [PATCH v2 0/3] Add support for QC08C format in iris driver

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: <s2qjimx4tq2jdnir7b5dljf4onsbcmvb5prxcvc22q76l5cgnz@wrgcqdrl26sb>
Date: Thu, 15 Jan 2026 10:08:10 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Dikshita Agarwal <dikshita.agarwal@....qualcomm.com>
Cc: Vikash Garodia <vikash.garodia@....qualcomm.com>,
        Abhinav Kumar <abhinav.kumar@...ux.dev>,
        Bryan O'Donoghue <bod@...nel.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/3] Add support for QC08C format in iris driver

On Wed, Oct 08, 2025 at 03:22:24PM +0530, Dikshita Agarwal wrote:
> Add support for the QC08C color format in both the encoder and decoder 
> paths of the iris driver. The changes include:
> 
> - Adding QC08C format handling in the driver for both encoding and 
> decoding.
> - Updating format enumeration to properly return supported formats.
> - Ensuring the correct HFI format is set for firmware communication.
> -Making all related changes required for seamless integration of QC08C 
> support.
> 
> The changes have been validated using v4l2-ctl, compliance, and GStreamer (GST) tests.
> Both GST and v4l2-ctl tests were performed using the NV12 format, as 
> these clients do not support the QCOM-specific QC08C format, and all 
> tests passed successfully.
> 
> During v4l2-ctl testing, a regression was observed when using the NV12 
> color format after adding QC08C support. A fix for this regression has 
> also been posted [1].
> 
> [1]: https://lore.kernel.org/linux-media/20250918103235.4066441-1-dikshita.agarwal@oss.qualcomm.com/T/#u 
> 
> Changes in v2:
> - Added separate patch to add support for HFI_PROP_OPB_ENABLE (Bryan)
> - Updated commit text to indicate QC08C is NV12 with UBWC compression (Bryan, Dmitry)
> - Renamed IRIS_FMT_UBWC to IRIS_FMT_QC08C (Dmitry)
> - Link to v1: https://lore.kernel.org/r/20250919-video-iris-ubwc-enable-v1-0-000d11edafd8@oss.qualcomm.com
> 
> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@....qualcomm.com>
> ---
> Dikshita Agarwal (3):
>       media: iris: Add support for HFI_PROP_OPB_ENABLE to control split mode
>       media: iris: Add support for QC08C format for decoder
>       media: iris: Add support for QC08C format for encoder
> 

Looking at the series again... What is the definition of V4L formats?
Are they expected to be self-compatible? Transferable between machines?
In DRM world we made a mistake, making use of a single non-parametrized
UBWC modifier, and then later we had to introduce OOB values to
represent different params of UBWC compressed images.

So, I wanted to ask, is single "UBWC-compressed NV12" enough for V4L2 or
should we have different format values (at least for different swizzle
and macrotile modes)?

-- 
With best wishes
Dmitry