From: Hans de Goede <hansg@kernel.org>
To: Ricardo Ribalda <ribalda@chromium.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org
Subject: Re: [PATCH v2 3/6] media: uvcvideo: Announce deprecation intentions for UVCIOC_CTRL_MAP
Date: Mon, 8 Dec 2025 12:17:21 +0100 [thread overview]
Message-ID: <f7cbf5ab-7564-4c81-84c9-b38b09e977f9@kernel.org> (raw)
In-Reply-To: <20251119-uvcdynctrl-v2-3-0359ffb98c9e@chromium.org>
Hi,
On 19-Nov-25 8:37 PM, Ricardo Ribalda wrote:
> The UVCIOC_CTRL_MAP lets userspace create a mapping for a custom
> control.
>
> This mapping is usually created by the uvcdynctrl userspace utility. We
> would like to get the mappings into the driver instead.
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
> ---
> Documentation/userspace-api/media/drivers/uvcvideo.rst | 2 ++
> drivers/media/usb/uvc/uvc_v4l2.c | 4 ++++
> 2 files changed, 6 insertions(+)
>
> diff --git a/Documentation/userspace-api/media/drivers/uvcvideo.rst b/Documentation/userspace-api/media/drivers/uvcvideo.rst
> index dbb30ad389ae4d53bc734b4269ebea20ecdd7535..b09d2f8ba66ecde67f1e35fd77858a505ad44eb1 100644
> --- a/Documentation/userspace-api/media/drivers/uvcvideo.rst
> +++ b/Documentation/userspace-api/media/drivers/uvcvideo.rst
> @@ -109,6 +109,8 @@ IOCTL reference
> UVCIOC_CTRL_MAP - Map a UVC control to a V4L2 control
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> +**This IOCTL is deprecated and will be eventually removed**
> +
> Argument: struct uvc_xu_control_mapping
>
> **Description**:
> diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c
> index 9e4a251eca88085a1b4e0e854370015855be92ee..03c64b5698bf4331fed8437fa6e9c726a07450bd 100644
> --- a/drivers/media/usb/uvc/uvc_v4l2.c
> +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> @@ -1044,6 +1044,8 @@ static long uvc_ioctl_default(struct file *file, void *priv, bool valid_prio,
> switch (cmd) {
> /* Dynamic controls. */
> case UVCIOC_CTRL_MAP:
> + pr_warn_once("uvcvideo: " DEPRECATED
> + "UVCIOC_CTRL_MAP ioctl will be eventually removed.\n");
> return uvc_ioctl_xu_ctrl_map(chain, arg);
>
> case UVCIOC_CTRL_QUERY:
Deprecating and then removing this is going to be a long slow process.
I was thinking that rather then remove it we would keep accepting the ioctl but instead
of calling uvc_ioctl_xu_ctrl_map() we would simply return 0. E.g. change the above to:
case UVCIOC_CTRL_MAP:
pr_warn_once("uvcvideo: " DEPRECATED
"UVCIOC_CTRL_MAP ioctl will eventually be ignored.\n");
return uvc_ioctl_xu_ctrl_map(chain, arg);
And then say in one year after a kernel with the above is released change it to:
case UVCIOC_CTRL_MAP:
pr_warn_once("uvcvideo: " DEPRECATED
"UVCIOC_CTRL_MAP ioctls are ignored.\n");
return 0;
I think removing it in 1 year is too soon, but ignoring it is ok. This does mean
that people will loose the custom v4l2-ctrls for which patch 2/6 is not adding
mappings into the driver in 1 year after a kernel with the warning is released...
I'm not 100% sure about this plan, so please let me know what you think. For
outright deprecation warning + full removal I think we need to wait at least
2 years after shipping a kernel with the deprecation warning.
Regards,
Hans
next prev parent reply other threads:[~2025-12-08 11:17 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-19 19:37 [PATCH v2 0/6] media: uvcvideo: Map known XU controls Ricardo Ribalda
2025-11-19 19:37 ` [PATCH v2 1/6] media: uvcvideo: Remove nodrop parameter Ricardo Ribalda
2025-12-08 10:54 ` Hans de Goede
2025-11-19 19:37 ` [PATCH v2 2/6] media: uvcvideo: Import standard controls from uvcdynctrl Ricardo Ribalda
2025-12-08 11:02 ` Hans de Goede
2025-12-08 11:12 ` Hans de Goede
2025-12-09 6:28 ` Ricardo Ribalda
2025-12-09 16:22 ` Hans de Goede
2025-11-19 19:37 ` [PATCH v2 3/6] media: uvcvideo: Announce deprecation intentions for UVCIOC_CTRL_MAP Ricardo Ribalda
2025-12-08 11:17 ` Hans de Goede [this message]
2025-12-09 6:41 ` Ricardo Ribalda
2025-12-09 16:27 ` Hans de Goede
2025-11-19 19:37 ` [PATCH v2 4/6] media: uvcvideo: Document how to format GUIDs Ricardo Ribalda
2025-12-08 11:19 ` Hans de Goede
2025-12-22 0:56 ` Laurent Pinchart
2025-11-19 19:37 ` [PATCH v2 5/6] media: uvcvideo: Introduce allow_privacy_override param Ricardo Ribalda
2025-11-19 21:54 ` Gergo Koteles
2025-11-19 22:09 ` Ricardo Ribalda
2025-12-08 11:58 ` Hans de Goede
2025-12-10 6:40 ` Ricardo Ribalda
2025-11-19 19:37 ` [PATCH v2 6/6] media: uvcvideo: RFC: Convert allow_privacy_override into Kconfig Ricardo Ribalda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f7cbf5ab-7564-4c81-84c9-b38b09e977f9@kernel.org \
--to=hansg@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=ribalda@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®