From: Hans de Goede <hansg@kernel.org>
To: Ricardo Ribalda <ribalda@chromium.org>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Hans de Goede <hdegoede@redhat.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Guennadi Liakhovetski <guennadi.liakhovetski@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org
Subject: Re: [PATCH v6 4/4] media: uvcvideo: Auto-set UVC_QUIRK_MSXU_META
Date: Tue, 17 Jun 2025 11:33:14 +0200 [thread overview]
Message-ID: <9233836e-c50e-4118-95f6-0be02dc0c45e@kernel.org> (raw)
In-Reply-To: <CANiDSCu1b2n9c7WH2ZHysOY2xV1RbV9Z6AHBuXXfF8fV8OwYgg@mail.gmail.com>
Hi,
On 16-Jun-25 11:02 PM, Ricardo Ribalda wrote:
> Hi Hans
>
> On Mon, 16 Jun 2025 at 22:47, Hans de Goede <hansg@kernel.org> wrote:
>>
>> Hi Ricardo,
>>
>> On 16-Jun-25 5:04 PM, Ricardo Ribalda wrote:
>>> Hi Hans
>>>
>>> On Mon, 16 Jun 2025 at 16:38, Hans de Goede <hansg@kernel.org> wrote:
>>>>
>>>> Hi Ricardo,
>>>>
>>>> On 4-Jun-25 14:16, Ricardo Ribalda wrote:
>>>>> If the camera supports the MSXU_CONTROL_METADATA control, auto set the
>>>>> MSXU_META quirk.
>>>>>
>>>>> Reviewed-by: Hans de Goede <hansg@kernel.org>
>>>>> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
>>>>> ---
>>>>> drivers/media/usb/uvc/uvc_metadata.c | 72 ++++++++++++++++++++++++++++++++++++
>>>>> include/linux/usb/uvc.h | 3 ++
>>>>> 2 files changed, 75 insertions(+)
>>>>>
>>>>> diff --git a/drivers/media/usb/uvc/uvc_metadata.c b/drivers/media/usb/uvc/uvc_metadata.c
>>>>> index df3f259271c675feb590c4534dad95b3b786f082..cd58427578ff413591b60abe0a210b90802dddc7 100644
>>>>> --- a/drivers/media/usb/uvc/uvc_metadata.c
>>>>> +++ b/drivers/media/usb/uvc/uvc_metadata.c
>>>>> @@ -10,6 +10,7 @@
>>>>> #include <linux/list.h>
>>>>> #include <linux/module.h>
>>>>> #include <linux/usb.h>
>>>>> +#include <linux/usb/uvc.h>
>>>>> #include <linux/videodev2.h>
>>>>>
>>>>> #include <media/v4l2-ioctl.h>
>>>>> @@ -188,11 +189,82 @@ static const struct v4l2_file_operations uvc_meta_fops = {
>>>>> .mmap = vb2_fop_mmap,
>>>>> };
>>>>>
>>>>> +static const u8 uvc_msxu_guid[16] = UVC_GUID_MSXU_1_5;
>>>>> +
>>>>> +static struct uvc_entity *uvc_meta_find_msxu(struct uvc_device *dev)
>>>>> +{
>>>>> + struct uvc_entity *entity;
>>>>> +
>>>>> + list_for_each_entry(entity, &dev->entities, list) {
>>>>> + if (!memcmp(entity->guid, uvc_msxu_guid, sizeof(entity->guid)))
>>>>> + return entity;
>>>>> + }
>>>>> +
>>>>> + return NULL;
>>>>> +}
>>>>> +
>>>>> +#define MSXU_CONTROL_METADATA 0x9
>>>>> +static int uvc_meta_detect_msxu(struct uvc_device *dev)
>>>>> +{
>>>>> + u32 *data __free(kfree) = NULL;
>>>>> + struct uvc_entity *entity;
>>>>> + int ret;
>>>>> +
>>>>> + entity = uvc_meta_find_msxu(dev);
>>>>> + if (!entity)
>>>>> + return 0;
>>>>> +
>>>>> + /*
>>>>> + * USB requires buffers aligned in a special way, simplest way is to
>>>>> + * make sure that query_ctrl will work is to kmalloc() them.
>>>>> + */
>>>>> + data = kmalloc(sizeof(*data), GFP_KERNEL);
>>>>> + if (!data)
>>>>> + return -ENOMEM;
>>>>> +
>>>>> + /* Check if the metadata is already enabled. */
>>>>> + ret = uvc_query_ctrl(dev, UVC_GET_CUR, entity->id, dev->intfnum,
>>>>> + MSXU_CONTROL_METADATA, data, sizeof(*data));
>>>>> + if (ret)
>>>>> + return 0;
>>>>> +
>>>>> + if (*data) {
>>>>> + dev->quirks |= UVC_QUIRK_MSXU_META;
>>>>> + return 0;
>>>>> + }
>>>>> +
>>>>> + /*
>>>>> + * We have seen devices that require 1 to enable the metadata, others
>>>>> + * requiring a value != 1 and others requiring a value >1. Luckily for
>>>>> + * us, the value from GET_MAX seems to work all the time.
>>>>> + */
>>>>> + ret = uvc_query_ctrl(dev, UVC_GET_MAX, entity->id, dev->intfnum,
>>>>> + MSXU_CONTROL_METADATA, data, sizeof(*data));
>>>>> + if (ret || !*data)
>>>>> + return 0;
>>>>> +
>>>>> + /*
>>>>> + * If we can set MSXU_CONTROL_METADATA, the device will report
>>>>> + * metadata.
>>>>> + */
>>>>> + ret = uvc_query_ctrl(dev, UVC_SET_CUR, entity->id, dev->intfnum,
>>>>> + MSXU_CONTROL_METADATA, data, sizeof(*data));
>>>>> + if (!ret)
>>>>> + dev->quirks |= UVC_QUIRK_MSXU_META;
>>>>
>>>> Since we set the ctrl to enable MSXU fmt metadata here, this means that
>>>> cameras which also support V4L2_META_FMT_D4XX will be switched to MSXU
>>>> metadata mode at probe() time.
>>>
>>> Not sure that I completely follow you. D4XX cameras will not be
>>> switched to MSXU, they will support MSXU and D4XX with the current
>>> patchset.
>>
>> Is MSXU an extension on top of D4XX ? If not then we need to tell
>> the camera which metadata we want in uvc_meta_v4l2_set_format()
>
> I think I know where the miss-comunication happened :)
>
> MSXU is indeed a superset of D4xx. D4xx metadata is formatted in MSXU.
>
> If an app fetches D4XX and MSXU from an Intel D4xx device, they are identical.
>
> Or in other words, if D4XX devices have MSXU_CONTROL_METADATA, they
> are probably today initialized with a value != 0.
Ok I see. But I still think the way this is handled in patch 3/4
is a bit "clunky". I think we should maybe add a 0 terminated
meta_format array to struct uvc_device and populate that during
probe with (again maybe) a uvc_device_add_metadata_fmt() helper?
Having such an array should make uvc_meta_v4l2_try_format() /
uvc_meta_v4l2_set_format() / uvc_meta_v4l2_enum_format() much
cleaner. And maybe we can even use a single implementation
for try and set?
Can you give this approach a try ?
Regards,
Hans
prev parent reply other threads:[~2025-06-17 9:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-04 12:16 [PATCH v6 0/4] media: uvcvideo: Introduce V4L2_META_FMT_UVC_MSXU_1_5 + other meta fixes Ricardo Ribalda
2025-06-04 12:16 ` [PATCH v6 1/4] media: uvcvideo: Do not mark valid metadata as invalid Ricardo Ribalda
2025-06-04 12:16 ` [PATCH v6 2/4] media: Documentation: Add note about UVCH length field Ricardo Ribalda
2025-06-04 12:16 ` [PATCH v6 3/4] media: uvcvideo: Introduce V4L2_META_FMT_UVC_MSXU_1_5 Ricardo Ribalda
2025-06-04 12:16 ` [PATCH v6 4/4] media: uvcvideo: Auto-set UVC_QUIRK_MSXU_META Ricardo Ribalda
2025-06-16 14:38 ` Hans de Goede
2025-06-16 15:04 ` Ricardo Ribalda
2025-06-16 20:47 ` Hans de Goede
2025-06-16 21:02 ` Ricardo Ribalda
2025-06-17 9:33 ` Hans de Goede [this message]
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=9233836e-c50e-4118-95f6-0be02dc0c45e@kernel.org \
--to=hansg@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=guennadi.liakhovetski@intel.com \
--cc=hdegoede@redhat.com \
--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;
as well as URLs for NNTP newsgroup(s).