From: Hans de Goede <hansg@kernel.org>
To: Ricardo Ribalda <ribalda@chromium.org>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org,
Manav Gautama <bandwidthcrunch@gmail.com>,
Martin Rubli <martin_rubli@logitech.com>
Subject: Re: [PATCH v2 2/6] media: uvcvideo: Import standard controls from uvcdynctrl
Date: Tue, 9 Dec 2025 17:22:34 +0100 [thread overview]
Message-ID: <2bf30256-7647-488a-a8d8-4b4d2f0af813@kernel.org> (raw)
In-Reply-To: <CANiDSCsrAvwygBrQLsF9RVOUGpdOEaOhzE90=c2CrW8GGe6-=g@mail.gmail.com>
Hi,
On 9-Dec-25 7:28 AM, Ricardo Ribalda wrote:
> Hi Hans
>
>
> On Mon, 8 Dec 2025 at 20:12, Hans de Goede <hansg@kernel.org> wrote:
>>
>> Hi,
>>
>> On 8-Dec-25 12:02 PM, Hans de Goede wrote:
>>> Hi Ricardo,
>>>
>>> Thank you very much for doing this, this has been on my own TODO list for
>>> a long time, so it is great to finally see this happen.
>>>
>>> On 19-Nov-25 8:37 PM, Ricardo Ribalda wrote:
>>>> The uvcdynctrl tool from libwebcam:
>>>> https://sourceforge.net/projects/libwebcam/
>>>> maps proprietary controls into v4l2 controls using the UVCIOC_CTRL_MAP
>>>> ioctl.
>>>>
>>>> The tool has not been updated for 10+ years now, and there is no reason
>>>> for the UVC driver to not do the mapping by itself.
>>>>
>>>> This patch adds the mappings from the uvcdynctrl into the driver. Hopefully
>>>> this effort can help in deprecating the UVCIOC_CTRL_MAP ioctl.
>>>
>>> ...
>>>
>>> Question what happens if uvcdynctrl is run after applying this patch ?
>>
>> Answering my own question here, we will hit:
>>
>> drivers/media/usb/uvc/uvc_ctrl.c: 3166:
>>
>> list_for_each_entry(map, &ctrl->info.mappings, list) {
>> if (mapping->id == map->id) {
>> uvc_dbg(dev, CONTROL,
>> "Can't add mapping '%s', control id 0x%08x already exists\n",
>> uvc_map_get_name(mapping), mapping->id);
>> ret = -EEXIST;
>> goto done;
>> }
>> }
>>
>> So uvcdynctrl will see an EEXIST error. I think we need to add an -EEXIST check
>> to uvc_ctrl_add_mapping() )or uvc_ioctl_xu_ctrl_map() which is the only caller of
>> uvc_ctrl_add_mapping()) and if -EEXIST is returned do a uvc_warn_once() that duplicate
>> mappings are being ignored and return 0 instead of -EEXIST to avoid breaking existing
>
> uvcdynctrl seems to handle this kind of error ok:
>
> https://sourceforge.net/p/libwebcam/code/ci/master/tree/libwebcam/dynctrl.c#l1215
>
> while(node_mapping) {
> CResult ret = process_mapping(node_mapping, ctx);
> if(ctx->info) {
> if(ret)
> ctx->info->stats.mappings.successful++;
> else
> ctx->info->stats.mappings.failed++;
> }
> node_mapping = xml_get_next_sibling_by_name(node_mapping, "mapping");
> }
>
> https://sourceforge.net/p/libwebcam/code/ci/master/tree/libwebcam/dynctrl.c#l1199
> if(v4l2_ret != 0
> #ifdef DYNCTRL_IGNORE_EEXIST_AFTER_PASS1
> && (ctx->pass == 1 || errno != EEXIST)
> #endif
> )
>
> https://sourceforge.net/p/libwebcam/code/ci/master/tree/libwebcam/libwebcam.h#l69
> /// Ignore EEXIST errors for the UVCIOC_CTRL_ADD and UVCIOC_CTRL_MAP ioctls for
> /// all but the first device. This is required if the driver uses
> global controls
> /// instead of per-device controls.
> #define DYNCTRL_IGNORE_EEXIST_AFTER_PASS1
>
>
> (BTW, I think the last comment ^^^ is wrong, it should be. Ignore
> EEXIST errors, or errors for second passes.
> But I might need a coffee :P)
>
>
> Looking at the debian codesearch:
> https://codesearch.debian.net/search?q=UVCIOC_CTRL_MAP+-path%3Aioctl.rs+-path%3Auvc_v4l2.c+-file%3Auvcvideo.rst+-file%3Auvc_ctrl.c+-file%3Auvcvideo.h&literal=1
>
> the only occurrence that I am no sure if it will properly handle -EEXIST is:
> https://sources.debian.org/src/chromium/143.0.7499.40-1/chrome/browser/ash/chromebox_for_meetings/xu_camera/xu_camera_service.cc?hl=400#L400
> But that is ash-> ChromeOS browser. I can ask the code owner to fix it
> if needed.
>
>
> I'd rather not add the quirk that you are proposing if possible. I
> would expect that any/all the userspace handles -EEXIST because the
> uvc control state outlives the userspace.
>
>
> Let me know what you think.
Based on what you wrote above I think that going with -EEXIST is ok for
now, we can always revisit if we get complaints about this.
Regards,
Hans
next prev parent reply other threads:[~2025-12-09 16:22 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 [this message]
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
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=2bf30256-7647-488a-a8d8-4b4d2f0af813@kernel.org \
--to=hansg@kernel.org \
--cc=bandwidthcrunch@gmail.com \
--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=martin_rubli@logitech.com \
--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®