Hi All, On 20-May-26 17:32, [email protected] 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 <[email protected]> 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 <[email protected]> --- 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
