mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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>,
	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 v7 4/5] media: uvcvideo: Introduce V4L2_META_FMT_UVC_MSXU_1_5
Date: Mon, 7 Jul 2025 13:52:10 +0200	[thread overview]
Message-ID: <13ee783b-7753-49f6-9efd-8989ddf0fe47@kernel.org> (raw)
In-Reply-To: <CANiDSCsqB6ktOXPg5S+He4bk8X_xA9y1r9AE9qc1AZ=edDYfrQ@mail.gmail.com>

Hi,

On 7-Jul-25 13:44, Ricardo Ribalda wrote:
> On Mon, 7 Jul 2025 at 13:34, Hans de Goede <hansg@kernel.org> wrote:
>>
>> Hi Ricardo,
>>
>> Thank you for the new version of this series.
>>
>> On 17-Jun-25 16:42, Ricardo Ribalda wrote:
>>> The UVC driver provides two metadata types V4L2_META_FMT_UVC, and
>>> V4L2_META_FMT_D4XX. The only difference between the two of them is that
>>> V4L2_META_FMT_UVC only copies PTS, SCR, size and flags, and
>>> V4L2_META_FMT_D4XX copies the whole metadata section.
>>>
>>> Now we only enable V4L2_META_FMT_D4XX for the Intel D4xx family of
>>> devices, but it is useful to have the whole metadata payload for any
>>> device where vendors include other metadata, such as the one described by
>>> Microsoft:
>>> https://learn.microsoft.com/en-us/windows-hardware/drivers/stream/mf-capture-metadata
>>>
>>> This patch introduces a new format V4L2_META_FMT_UVC_MSXU_1_5, that is
>>> identical to V4L2_META_FMT_D4XX.
>>>
>>> Let the user enable this format with a quirk for now. This way they can
>>> test if their devices provide useful metadata without rebuilding the
>>> kernel. They can later contribute patches to auto-quirk their devices.
>>> We will also work in methods to auto-detect devices compatible with this
>>> new metadata format.
>>>
>>> Suggested-by: Hans de Goede <hdegoede@redhat.com>
>>> Reviewed-by: Hans de Goede <hansg@kernel.org>
>>> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
>>> ---
>>>  .../userspace-api/media/v4l/meta-formats.rst       |  1 +
>>>  .../media/v4l/metafmt-uvc-msxu-1-5.rst             | 23 ++++++++++++++++++++++
>>>  MAINTAINERS                                        |  1 +
>>>  drivers/media/usb/uvc/uvc_metadata.c               | 20 +++++++++++++++++--
>>>  drivers/media/usb/uvc/uvcvideo.h                   |  1 +
>>>  drivers/media/v4l2-core/v4l2-ioctl.c               |  1 +
>>>  include/uapi/linux/videodev2.h                     |  1 +
>>>  7 files changed, 46 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/userspace-api/media/v4l/meta-formats.rst b/Documentation/userspace-api/media/v4l/meta-formats.rst
>>> index bb6876cfc271e1a0543eee4209d6251e1a6a73cc..0de80328c36bf148051a19abe9e5241234ddfe5c 100644
>>> --- a/Documentation/userspace-api/media/v4l/meta-formats.rst
>>> +++ b/Documentation/userspace-api/media/v4l/meta-formats.rst
>>> @@ -20,6 +20,7 @@ These formats are used for the :ref:`metadata` interface only.
>>>      metafmt-pisp-fe
>>>      metafmt-rkisp1
>>>      metafmt-uvc
>>> +    metafmt-uvc-msxu-1-5
>>>      metafmt-vivid
>>>      metafmt-vsp1-hgo
>>>      metafmt-vsp1-hgt
>>> diff --git a/Documentation/userspace-api/media/v4l/metafmt-uvc-msxu-1-5.rst b/Documentation/userspace-api/media/v4l/metafmt-uvc-msxu-1-5.rst
>>> new file mode 100644
>>> index 0000000000000000000000000000000000000000..dd1c3076df243d770a13e7f6d07c3296a269e16a
>>> --- /dev/null
>>> +++ b/Documentation/userspace-api/media/v4l/metafmt-uvc-msxu-1-5.rst
>>> @@ -0,0 +1,23 @@
>>> +.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
>>> +
>>> +.. _v4l2-meta-fmt-uvc-msxu-1-5:
>>> +
>>> +***********************************
>>> +V4L2_META_FMT_UVC_MSXU_1_5 ('UVCM')
>>> +***********************************
>>> +
>>> +Microsoft(R)'s UVC Payload Metadata.
>>> +
>>> +
>>> +Description
>>> +===========
>>> +
>>> +V4L2_META_FMT_UVC_MSXU_1_5 buffers follow the metadata buffer layout of
>>> +V4L2_META_FMT_UVC with the only difference that it includes all the UVC
>>> +metadata in the `buffer[]` field, not just the first 2-12 bytes.
>>> +
>>> +The metadata format follows the specification from Microsoft(R) [1].
>>> +
>>> +.. _1:
>>> +
>>> +[1] https://docs.microsoft.com/en-us/windows-hardware/drivers/stream/uvc-extensions-1-5
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index e8f3dc93a56921924f57e7d5a03ea2fa182a4448..87101630e528297c57b22ffc2fe553e3864d25cc 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -25816,6 +25816,7 @@ S:    Maintained
>>>  W:   http://www.ideasonboard.org/uvc/
>>>  T:   git git://linuxtv.org/media.git
>>>  F:   Documentation/userspace-api/media/drivers/uvcvideo.rst
>>> +F:   Documentation/userspace-api/media/v4l/metafmt-uvc-msxu-1-5.rst
>>>  F:   Documentation/userspace-api/media/v4l/metafmt-uvc.rst
>>>  F:   drivers/media/common/uvc.c
>>>  F:   drivers/media/usb/uvc/
>>> diff --git a/drivers/media/usb/uvc/uvc_metadata.c b/drivers/media/usb/uvc/uvc_metadata.c
>>> index bc84e849174397f41d1e20bf890a876eeb5a9c67..b09f81d907d64f7d7a3b0dc52de319879b7e68be 100644
>>> --- a/drivers/media/usb/uvc/uvc_metadata.c
>>> +++ b/drivers/media/usb/uvc/uvc_metadata.c
>>> @@ -190,13 +190,29 @@ int uvc_meta_init(struct uvc_device *dev)
>>>       static const u32 uvch_only[] = {V4L2_META_FMT_UVC, 0};
>>>       static const u32 d4xx_format[] = {V4L2_META_FMT_UVC, V4L2_META_FMT_D4XX,
>>>                                         0};
>>> +     static const u32 all_formats[] = {V4L2_META_FMT_UVC, V4L2_META_FMT_D4XX,
>>> +                                       V4L2_META_FMT_UVC_MSXU_1_5, 0};
>>> +     static const u32 ms_format[] = {V4L2_META_FMT_UVC,
>>> +                                     V4L2_META_FMT_UVC_MSXU_1_5, 0};
>>
>> Hmm, this does not look great, I guess we are not expecting any
>> new metadata formats soon but just needing the 4 arrays here and
>> then ... (continued below).
> 
> Yeah, this looks better :)
> 
> 
> Will implement it as you describe. Just a couple of comments.
> 
> 
> 
>>
>>
>>> +     bool support_msxu;
>>> +
>>> +     support_msxu = dev->quirks & UVC_QUIRK_MSXU_META;
>>>
>>>       switch (dev->info->meta_format) {
>>> +     case V4L2_META_FMT_UVC_MSXU_1_5:
>>> +             dev->meta_formats = ms_format;
>>> +             break;
>>>       case V4L2_META_FMT_D4XX:
>>> -             dev->meta_formats = d4xx_format;
>>> +             if (support_msxu)
>>> +                     dev->meta_formats = all_formats;
>>> +             else
>>> +                     dev->meta_formats = d4xx_format;
>>>               break;
>>>       case 0:
>>> -             dev->meta_formats = uvch_only;
>>> +             if (support_msxu)
>>> +                     dev->meta_formats = ms_format;
>>> +             else
>>> +                     dev->meta_formats = uvch_only;
>>
>> Also having these if else's here both don't look nice /
>> this does not feel clean.
>>
>> My suggestion would be to instead do the following:
>>
>> 1. Add a #define UVC_MAX_META_DATA_FORMATS 3 to uvcvideo.h
>> 2. In the struct uvc_device definition change meta_formats to:
>>
>>         u32 meta_formats[UVC_MAX_META_DATA_FORMATS + 1];
>>
>> 3. Change uvc_meta_init() to:
>>
>> void uvc_meta_init(struct uvc_device *dev)
>> {
>>         unsigned int i = 0;
>>
>>         dev->meta_formats[i++] = V4L2_META_FMT_UVC;
>>
>>         if (dev->info->meta_format)
>>                 dev->meta_formats[i++] = dev->info->meta_format;
>>
>>         if (dev->quirks & UVC_QUIRK_MSXU_META)
> 
>          if (dev->quirks & UVC_QUIRK_MSXU_META) &&
> dev->meta_formats[i-1] != V4L2_META_FMT_UVC_MSXU_1_5)
>>                 dev->meta_formats[i++] = V4L2_META_FMT_UVC_MSXU_1_5;
>>
>>         /* IMPORTANT for new meta-formats update UVC_MAX_META_DATA_FORMATS */
> 
> Do we really need this comment? Even if we add more formats the total
> number of formats supported will never be more than 3.
> 
> FMT_UVC, device_specific, msxu

The comment is at the place where one would add a new if in case
for some reason we do add another path to add a meta-format in
that case if all 3 (with the new if) if conditions evaluate to
true then we would overrun the array.

Unfortunately there is no way to do e.g. a static_assert()
for that, which is why I still believe at least having
the comment would be good.

That and/or add a:

	WARN_ON(i > UVC_MAX_META_DATA_FORMATS);

Before adding the final 0 terminator. I actually had
the WARN_ON in there first, but a comment seemed to make
more sense...

Regards,

Hans





>>         dev->meta_formats[i++] = 0;
>> }
>>
>> Note uvc_meta_init() now also is void, so no more need to error check it.
>>
>> The only downside I can see is that if we ever actually start setting
>> dev->info->meta_format = V4L2_META_FMT_UVC_MSXU_1_5 and a user manually
>> enables the quirk we get V4L2_META_FMT_UVC_MSXU_1_5 listed twice, but
>> that should not cause any issues and normally that will never happen.
>>
>> IMHO this is better, then the switch-case + if-else code.
>>
>> Stating the obvious: some / most of these changes should be done in patch 3/5
>> already.
>>
>> Regards,
>>
>> Hans
>>
>>
>>
>>
>>>               break;
>>>       default:
>>>               dev_err(&dev->udev->dev, "Unknown metadata format 0x%x\n",
>>> diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
>>> index 502f1d5608637cd28ce6f01aee31c4f5df160081..3578ce72fb6a1153ae79c244ec10093e8efdd739 100644
>>> --- a/drivers/media/usb/uvc/uvcvideo.h
>>> +++ b/drivers/media/usb/uvc/uvcvideo.h
>>> @@ -77,6 +77,7 @@
>>>  #define UVC_QUIRK_DISABLE_AUTOSUSPEND        0x00008000
>>>  #define UVC_QUIRK_INVALID_DEVICE_SOF 0x00010000
>>>  #define UVC_QUIRK_MJPEG_NO_EOF               0x00020000
>>> +#define UVC_QUIRK_MSXU_META          0x00040000
>>>
>>>  /* Format flags */
>>>  #define UVC_FMT_FLAG_COMPRESSED              0x00000001
>>> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
>>> index 650dc1956f73d2f1943b56c42140c7b8d757259f..ba508f7fb577021497009ab23a7be5add23fd08c 100644
>>> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
>>> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
>>> @@ -1459,6 +1459,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
>>>       case V4L2_META_FMT_VSP1_HGO:    descr = "R-Car VSP1 1-D Histogram"; break;
>>>       case V4L2_META_FMT_VSP1_HGT:    descr = "R-Car VSP1 2-D Histogram"; break;
>>>       case V4L2_META_FMT_UVC:         descr = "UVC Payload Header Metadata"; break;
>>> +     case V4L2_META_FMT_UVC_MSXU_1_5:        descr = "UVC MSXU Metadata"; break;
>>>       case V4L2_META_FMT_D4XX:        descr = "Intel D4xx UVC Metadata"; break;
>>>       case V4L2_META_FMT_VIVID:       descr = "Vivid Metadata"; break;
>>>       case V4L2_META_FMT_RK_ISP1_PARAMS:      descr = "Rockchip ISP1 3A Parameters"; break;
>>> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
>>> index 9e3b366d5fc79d8a04c6f0752858fc23363db65c..75f2096b2d4fed5e0235ea4732d35044ff77a98b 100644
>>> --- a/include/uapi/linux/videodev2.h
>>> +++ b/include/uapi/linux/videodev2.h
>>> @@ -861,6 +861,7 @@ struct v4l2_pix_format {
>>>  #define V4L2_META_FMT_VSP1_HGT    v4l2_fourcc('V', 'S', 'P', 'T') /* R-Car VSP1 2-D Histogram */
>>>  #define V4L2_META_FMT_UVC         v4l2_fourcc('U', 'V', 'C', 'H') /* UVC Payload Header metadata */
>>>  #define V4L2_META_FMT_D4XX        v4l2_fourcc('D', '4', 'X', 'X') /* D4XX Payload Header metadata */
>>> +#define V4L2_META_FMT_UVC_MSXU_1_5  v4l2_fourcc('U', 'V', 'C', 'M') /* UVC MSXU metadata */
>>>  #define V4L2_META_FMT_VIVID    v4l2_fourcc('V', 'I', 'V', 'D') /* Vivid Metadata */
>>>
>>>  /* Vendor specific - used for RK_ISP1 camera sub-system */
>>>
>>
> 
> 


  reply	other threads:[~2025-07-07 11:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-17 14:42 [PATCH v7 0/5] media: uvcvideo: Introduce V4L2_META_FMT_UVC_MSXU_1_5 + other meta fixes Ricardo Ribalda
2025-06-17 14:42 ` [PATCH v7 1/5] media: uvcvideo: Do not mark valid metadata as invalid Ricardo Ribalda
2025-06-17 14:42 ` [PATCH v7 2/5] media: Documentation: Add note about UVCH length field Ricardo Ribalda
2025-06-17 14:42 ` [PATCH v7 3/5] media: uvcvideo: Introduce dev->meta_formats Ricardo Ribalda
2025-07-07 11:35   ` Hans de Goede
2025-06-17 14:42 ` [PATCH v7 4/5] media: uvcvideo: Introduce V4L2_META_FMT_UVC_MSXU_1_5 Ricardo Ribalda
2025-07-07 11:34   ` Hans de Goede
2025-07-07 11:44     ` Ricardo Ribalda
2025-07-07 11:52       ` Hans de Goede [this message]
2025-06-17 14:42 ` [PATCH v7 5/5] media: uvcvideo: Auto-set UVC_QUIRK_MSXU_META 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=13ee783b-7753-49f6-9efd-8989ddf0fe47@kernel.org \
    --to=hansg@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=guennadi.liakhovetski@intel.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

all inboxes | Powered by JetHome®