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: <50137983757d754609d8164dbdfc429b32e3d6b5.camel@ndufresne.ca>
Date: Thu, 15 Jan 2026 09:02:07 -0500
From: Nicolas Dufresne <nicolas@...fresne.ca>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>, 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

Le jeudi 15 janvier 2026 à 10:08 +0200, Dmitry Baryshkov a écrit :
> 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)?

Our expectation is that the decoder will produce the same format regardless the
resolution. And that format should be shareable, so that same format coming from
two drivers means the same thing without out of band data, except that
resolution and strides are needed oob anyway and can obviously be used as an
acceptable workaround the issue you describe. It should also have a single
translation to DRM fourcc + modifier, and hopefully the other way around is
possible too, otherwise its a bit broken and unusable.

So bottom line, since V4L2 does not have modifiers, you have to treat one V4L2
format as a pair of DRM fourcc + modifier. Decoders typically only support a
subset, or hardware engineers can generally pick a handful of performant
configurations that works for all cases (its all 2D with similarly sized
macroblocks). Since these formats are only usable when consumed by GPU or
display controllers, its important that all party uses the same convention for
the limited information available.

Nicolas

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