Re: [PATCH v3 13/15] media: qcom: camss: Add CAMSS Offline Processing Engine driver

[Hans de Goede]

Hi All,

On 20-May-26 17:32, johannes.goede@xxxxxxxxxxxxxxxx wrote:

> 4. The v3 driver limits supported capture formats for the ope_disp_output
>    node (ope_enum_fmt_vid_cap()) to those matching ctx->proc_mbus_code, but
>    this not how this supposed to work. For media-controller centric
>    drivers, userspace is supposed to be able to enumerate all supported output
>    formats, as well as output formats for a specific mbus-code.
> 
>    This is controlled by the v4l2_fmtdesc.mbus_code field, if this is 0
>    then all formats should be returned and if it is set then only formats
>    which can be outputted for that mbus-code should be returned.
>
>    No active driver state like ctx->proc_mbus_code should be queried,
>    setting a compatible mbus code on the sink pad which is the source
>    for the /dev/video# capture node is userspace's responsibility.
> 
>    Also see:
>    https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/vidioc-enum-fmt.html 
>    "Regardless of the value of the mbus_code field, the enumerated image
>     formats shall not depend on the active configuration of the video
>     device or device pipeline."

FYI attached is a patch fixing this, feel free to squash into the next version.

Regards,

Hans
From a133927c28ed24dbd5fec0b48de8718e67a0ada2 Mon Sep 17 00:00:00 2001
From: Hans de Goede <johannes.goede@xxxxxxxxxxxxxxxx>
Date: Tue, 19 May 2026 21:49:07 +0200
Subject: [PATCH 1/2] media: qcom: camss: OPE: Fix ope_enum_fmt_vid_cap()

The v3 driver limits supported capture formats for the ope_disp_output
node (ope_enum_fmt_vid_cap()) to those matching ctx->proc_mbus_code, but
this not how this supposed to work. For media-controller centric
drivers, userspace is supposed to be able to enumerate all supported output
formats, as well as output formats for a specific mbus-code.

This is controlled by the v4l2_fmtdesc.mbus_code field, if this is 0
then all formats should be returned and if it is set then only formats
which can be outputted for that mbus-code should be returned.

No active driver state like ctx->proc_mbus_code should be queried,
setting a compatible mbus code on the sink pad which is the source
for the /dev/video# capture node is userspace's responsibility.

Also see:
https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/vidioc-enum-fmt.html
"Regardless of the value of the mbus_code field, the enumerated image
 formats shall not depend on the active configuration of the video
 device or device pipeline."

Note as for the source-pad feeding into the sink-pad lining up fmt /
mbus-code wise, this is also userspace's responsibility and should be
checked by calling media_pipeline_start() at stream-on time.

Signed-off-by: Hans de Goede <johannes.goede@xxxxxxxxxxxxxxxx>
---
 drivers/media/platform/qcom/camss/camss-isp-ope.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/qcom/camss/camss-isp-ope.c b/drivers/media/platform/qcom/camss/camss-isp-ope.c
index 1febe3e7417f..495d4b0b101f 100644
--- a/drivers/media/platform/qcom/camss/camss-isp-ope.c
+++ b/drivers/media/platform/qcom/camss/camss-isp-ope.c
@@ -1800,7 +1800,7 @@ static int ope_enum_fmt_vid_cap(struct file *file, void *priv, struct v4l2_fmtde
 	unsigned int i, n = 0;
 
 	for (i = 0; i < ARRAY_SIZE(ope_output_fmts); i++) {
-		if (ope_output_fmts[i].mbus_code != ctx->proc_mbus_code)
+		if (f->mbus_code && ope_output_fmts[i].mbus_code != f->mbus_code)
 			continue;
 		if (n++ == f->index) {
 			f->pixelformat = ope_output_fmts[i].fourcc;
-- 
2.54.0