uvcvideo regression: loss of access to full UVC payload header for generic UVC devices since 6.17

uvcvideo regression: loss of access to full UVC payload header for generic UVC devices since 6.17

[Itay Perl]

Hello,

I'm observing a behavior change in uvcvideo starting with kernel 6.17 that
appears to remove userspace access to the full UVC payload header on generic UVC
devices.

In kernels up to 6.16, requesting a metadata format of 0 allowed userspace to receive the
complete UVC header. uvc_meta_v4l2_try_format had

    fmt->dataformat = fmeta == dev->info->meta_format ? fmeta : V4L2_META_FMT_UVC;

and since dev->info->meta_format was 0 for generic devices, format 0 was accepted as
the metadata format.

Since 6.17, requesting 0 falls back to V4L2_META_FMT_UVC which only exposes the
standard portion of the header to userspace. As a result, there is currently no
mechanism for userspace to access the full UVC header for generic devices.

Would restoring the previous behavior be acceptable for compatibility?
Alternatively (or additionally), would it make sense to introduce a dedicated
metadata format that allows userspace to request the full UVC header for
generic devices?

Regards,
Itay

Re: uvcvideo regression: loss of access to full UVC payload header for generic UVC devices since 6.17

[Ricardo Ribalda]

Hi Itay

On Wed, 18 Feb 2026 at 11:59, Itay Perl <itay.perl@q.ai> wrote:
>
> Hello,
>
> I'm observing a behavior change in uvcvideo starting with kernel 6.17 that
> appears to remove userspace access to the full UVC payload header on generic UVC
> devices.
>
> In kernels up to 6.16, requesting a metadata format of 0 allowed userspace to receive the
> complete UVC header. uvc_meta_v4l2_try_format had
>
>     fmt->dataformat = fmeta == dev->info->meta_format ? fmeta : V4L2_META_FMT_UVC;

That looks like a bug in the original code :).

>
> and since dev->info->meta_format was 0 for generic devices, format 0 was accepted as
> the metadata format.
>
> Since 6.17, requesting 0 falls back to V4L2_META_FMT_UVC which only exposes the
> standard portion of the header to userspace. As a result, there is currently no
> mechanism for userspace to access the full UVC header for generic devices.
>
> Would restoring the previous behavior be acceptable for compatibility?
> Alternatively (or additionally), would it make sense to introduce a dedicated
> metadata format that allows userspace to request the full UVC header for
> generic devices?

By any chance the device that you are using supports
V4L2_META_FMT_UVC_MSXU_1_5 ?
If the device exposes the UVC_MSXU_CONTROL_METADATA control, that
format should be available, and it provices access to all the UVC
header as you had before.

Alternatively, if this is needed for a specific device you could send
a patch adding the UVC_QUIRK_MSXU_META for that device.
Would that work for you?

>
> Regards,
> Itay




--
Ricardo Ribalda

Re: uvcvideo regression: loss of access to full UVC payload header for generic UVC devices since 6.17

[Itay Perl]

Hi Ricardo,

________________________________________
From: Ricardo Ribalda <ribalda@chromium.org>
Sent: 18 February 2026 19:17
To: Itay Perl <itay.perl@q.ai>; Hans de Goede <hansg@kernel.org>; Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: linux-media@vger.kernel.org <linux-media@vger.kernel.org>; Itay Chamiel <itay.chamiel@q.ai>
Subject: Re: uvcvideo regression: loss of access to full UVC payload header for generic UVC devices since 6.17

> On Wed, 18 Feb 2026 at 11:59, Itay Perl <itay.perl@q.ai> wrote:
> > Would restoring the previous behavior be acceptable for compatibility?
> > Alternatively (or additionally), would it make sense to introduce a dedicated
> > metadata format that allows userspace to request the full UVC header for
> > generic devices?
> 
> By any chance the device that you are using supports
> V4L2_META_FMT_UVC_MSXU_1_5 ?
> If the device exposes the UVC_MSXU_CONTROL_METADATA control, that
> format should be available, and it provices access to all the UVC
> header as you had before.
>
> Alternatively, if this is needed for a specific device you could send
> a patch adding the UVC_QUIRK_MSXU_META for that device.
> Would that work for you?

My device is an internal development platform and does not have a public VID/PID
that could reasonably be added to the driver.

I may be able to implement the MSXU control on the device side as a workaround,
but I'm concerned that this could cause issues when the device is used on a
Windows machine, which may expect the UVC header to follow a certain
format when MSXU is present.

---
Regards,
Itay

Re: uvcvideo regression: loss of access to full UVC payload header for generic UVC devices since 6.17

[Laurent Pinchart]

On Wed, Feb 18, 2026 at 11:56:28AM +0000, Itay Perl wrote:
> On 18 February 2026 19:17, Ricardo Ribalda wrote:
> > On Wed, 18 Feb 2026 at 11:59, Itay Perl wrote:
> > > Would restoring the previous behavior be acceptable for compatibility?
> > > Alternatively (or additionally), would it make sense to introduce a dedicated
> > > metadata format that allows userspace to request the full UVC header for
> > > generic devices?
> > 
> > By any chance the device that you are using supports
> > V4L2_META_FMT_UVC_MSXU_1_5 ?
> > If the device exposes the UVC_MSXU_CONTROL_METADATA control, that
> > format should be available, and it provices access to all the UVC
> > header as you had before.
> >
> > Alternatively, if this is needed for a specific device you could send
> > a patch adding the UVC_QUIRK_MSXU_META for that device.
> > Would that work for you?
> 
> My device is an internal development platform and does not have a public VID/PID
> that could reasonably be added to the driver.
> 
> I may be able to implement the MSXU control on the device side as a workaround,
> but I'm concerned that this could cause issues when the device is used on a
> Windows machine, which may expect the UVC header to follow a certain
> format when MSXU is present.

Does your device implement a vendor-specific metadata format ?

-- 
Regards,

Laurent Pinchart

Re: uvcvideo regression: loss of access to full UVC payload header for generic UVC devices since 6.17

[Itay Perl]

________________________________________
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Sent: 19 February 2026 06:22
To: Itay Perl <itay.perl@q.ai>
Cc: Ricardo Ribalda <ribalda@chromium.org>; Hans de Goede <hansg@kernel.org>; linux-media@vger.kernel.org <linux-media@vger.kernel.org>; Itay Chamiel <itay.chamiel@q.ai>
Subject: Re: uvcvideo regression: loss of access to full UVC payload header for generic UVC devices since 6.17
 
> On Wed, Feb 18, 2026 at 11:56:28AM +0000, Itay Perl wrote:
> > On 18 February 2026 19:17, Ricardo Ribalda wrote:
> > > On Wed, 18 Feb 2026 at 11:59, Itay Perl wrote:
> > > > Would restoring the previous behavior be acceptable for compatibility?
> > > > Alternatively (or additionally), would it make sense to introduce a dedicated
> > > > metadata format that allows userspace to request the full UVC header for
> > > > generic devices?
> > >
> > > By any chance the device that you are using supports
> > > V4L2_META_FMT_UVC_MSXU_1_5 ?
> > > If the device exposes the UVC_MSXU_CONTROL_METADATA control, that
> > > format should be available, and it provices access to all the UVC
> > > header as you had before.
> > >
> > > Alternatively, if this is needed for a specific device you could send
> > > a patch adding the UVC_QUIRK_MSXU_META for that device.
> > > Would that work for you?
> >
> > My device is an internal development platform and does not have a public VID/PID
> > that could reasonably be added to the driver.
> >
> > I may be able to implement the MSXU control on the device side as a workaround,
> > but I'm concerned that this could cause issues when the device is used on a
> > Windows machine, which may expect the UVC header to follow a certain
> > format when MSXU is present.
> 
> Does your device implement a vendor-specific metadata format ?

Yes, the device uses a vendor-specific metadata format to attach
platform-specific data to each frame.  This is the most straightforward way to
add per-frame metadata without otherwise affecting UVC functionality.  We have
used this method successfully on Linux (using the 0-format hack) and on
Windows, where it required a registry configuration but was otherwise
supported.

---
Regards,
Itay

Re: uvcvideo regression: loss of access to full UVC payload header for generic UVC devices since 6.17

[Laurent Pinchart]

On Thu, Feb 19, 2026 at 06:03:49AM +0000, Itay Perl wrote:
> ON 19 February 2026 06:22, Laurent Pinchart wrote:
> > On Wed, Feb 18, 2026 at 11:56:28AM +0000, Itay Perl wrote:
> > > On 18 February 2026 19:17, Ricardo Ribalda wrote:
> > > > On Wed, 18 Feb 2026 at 11:59, Itay Perl wrote:
> > > > > Would restoring the previous behavior be acceptable for compatibility?
> > > > > Alternatively (or additionally), would it make sense to introduce a dedicated
> > > > > metadata format that allows userspace to request the full UVC header for
> > > > > generic devices?
> > > >
> > > > By any chance the device that you are using supports
> > > > V4L2_META_FMT_UVC_MSXU_1_5 ?
> > > > If the device exposes the UVC_MSXU_CONTROL_METADATA control, that
> > > > format should be available, and it provices access to all the UVC
> > > > header as you had before.
> > > >
> > > > Alternatively, if this is needed for a specific device you could send
> > > > a patch adding the UVC_QUIRK_MSXU_META for that device.
> > > > Would that work for you?
> > >
> > > My device is an internal development platform and does not have a public VID/PID
> > > that could reasonably be added to the driver.
> > >
> > > I may be able to implement the MSXU control on the device side as a workaround,
> > > but I'm concerned that this could cause issues when the device is used on a
> > > Windows machine, which may expect the UVC header to follow a certain
> > > format when MSXU is present.
> > 
> > Does your device implement a vendor-specific metadata format ?
> 
> Yes, the device uses a vendor-specific metadata format to attach
> platform-specific data to each frame.  This is the most straightforward way to
> add per-frame metadata without otherwise affecting UVC functionality.  We have
> used this method successfully on Linux (using the 0-format hack) and on
> Windows, where it required a registry configuration but was otherwise
> supported.

To support that device on Linux, the right way is to define a meta
format (such as V4L2_META_FMT_UVC and V4L2_META_FMT_UVC_MSXU_1_5) and
either add a VID:PID entry to the driver's uvc_ids[] array if the number
of devices is small, or define an XU that advertises support for the
format if you expect a larger number of devices. The metadata format
needs to be documented.

-- 
Regards,

Laurent Pinchart

Re: uvcvideo regression: loss of access to full UVC payload header for generic UVC devices since 6.17

[Itay Perl]

________________________________________
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Sent: 19 February 2026 16:21
To: Itay Perl <itay.perl@q.ai>
Cc: Ricardo Ribalda <ribalda@chromium.org>; Hans de Goede <hansg@kernel.org>; linux-media@vger.kernel.org <linux-media@vger.kernel.org>; Itay Chamiel <itay.chamiel@q.ai>
Subject: Re: uvcvideo regression: loss of access to full UVC payload header for generic UVC devices since 6.17

> On Thu, Feb 19, 2026 at 06:03:49AM +0000, Itay Perl wrote:
> > ON 19 February 2026 06:22, Laurent Pinchart wrote:
> > > On Wed, Feb 18, 2026 at 11:56:28AM +0000, Itay Perl wrote:
> > > > On 18 February 2026 19:17, Ricardo Ribalda wrote:
> > > > > On Wed, 18 Feb 2026 at 11:59, Itay Perl wrote:
> > > > > > Would restoring the previous behavior be acceptable for compatibility?
> > > > > > Alternatively (or additionally), would it make sense to introduce a dedicated
> > > > > > metadata format that allows userspace to request the full UVC header for
> > > > > > generic devices?
> > > > >
> > > > > By any chance the device that you are using supports
> > > > > V4L2_META_FMT_UVC_MSXU_1_5 ?
> > > > > If the device exposes the UVC_MSXU_CONTROL_METADATA control, that
> > > > > format should be available, and it provices access to all the UVC
> > > > > header as you had before.
> > > > >
> > > > > Alternatively, if this is needed for a specific device you could send
> > > > > a patch adding the UVC_QUIRK_MSXU_META for that device.
> > > > > Would that work for you?
> > > >
> > > > My device is an internal development platform and does not have a public VID/PID
> > > > that could reasonably be added to the driver.
> > > >
> > > > I may be able to implement the MSXU control on the device side as a workaround,
> > > > but I'm concerned that this could cause issues when the device is used on a
> > > > Windows machine, which may expect the UVC header to follow a certain
> > > > format when MSXU is present.
> > >
> > > Does your device implement a vendor-specific metadata format ?
> >
> > Yes, the device uses a vendor-specific metadata format to attach
> > platform-specific data to each frame.  This is the most straightforward way to
> > add per-frame metadata without otherwise affecting UVC functionality.  We have
> > used this method successfully on Linux (using the 0-format hack) and on
> > Windows, where it required a registry configuration but was otherwise
> > supported.
>
> To support that device on Linux, the right way is to define a meta
> format (such as V4L2_META_FMT_UVC and V4L2_META_FMT_UVC_MSXU_1_5) and
> either add a VID:PID entry to the driver's uvc_ids[] array if the number
> of devices is small, or define an XU that advertises support for the
> format if you expect a larger number of devices. The metadata format
> needs to be documented.

I understand the device-specific metadata approach via uvc_ids. However, my
device is an internal development platform not intended for public
availability, so adding specific support for it in the kernel would not be
appropriate.

Would it be reasonable to consider a generic metadata format (such as
V4L2_META_FMT_UVC_RAW/EXT) that could be used with generic devices? This could
be a useful feature for UVC device development and testing in general.

---
Regards,
Itay

Re: uvcvideo regression: loss of access to full UVC payload header for generic UVC devices since 6.17

[Laurent Pinchart]

On Thu, Feb 19, 2026 at 09:01:15AM +0000, Itay Perl wrote:
> On 19 February 2026 16:21, Laurent Pinchart wrote:
> > On Thu, Feb 19, 2026 at 06:03:49AM +0000, Itay Perl wrote:
> > > ON 19 February 2026 06:22, Laurent Pinchart wrote:
> > > > On Wed, Feb 18, 2026 at 11:56:28AM +0000, Itay Perl wrote:
> > > > > On 18 February 2026 19:17, Ricardo Ribalda wrote:
> > > > > > On Wed, 18 Feb 2026 at 11:59, Itay Perl wrote:
> > > > > > > Would restoring the previous behavior be acceptable for compatibility?
> > > > > > > Alternatively (or additionally), would it make sense to introduce a dedicated
> > > > > > > metadata format that allows userspace to request the full UVC header for
> > > > > > > generic devices?
> > > > > >
> > > > > > By any chance the device that you are using supports
> > > > > > V4L2_META_FMT_UVC_MSXU_1_5 ?
> > > > > > If the device exposes the UVC_MSXU_CONTROL_METADATA control, that
> > > > > > format should be available, and it provices access to all the UVC
> > > > > > header as you had before.
> > > > > >
> > > > > > Alternatively, if this is needed for a specific device you could send
> > > > > > a patch adding the UVC_QUIRK_MSXU_META for that device.
> > > > > > Would that work for you?
> > > > >
> > > > > My device is an internal development platform and does not have a public VID/PID
> > > > > that could reasonably be added to the driver.
> > > > >
> > > > > I may be able to implement the MSXU control on the device side as a workaround,
> > > > > but I'm concerned that this could cause issues when the device is used on a
> > > > > Windows machine, which may expect the UVC header to follow a certain
> > > > > format when MSXU is present.
> > > >
> > > > Does your device implement a vendor-specific metadata format ?
> > >
> > > Yes, the device uses a vendor-specific metadata format to attach
> > > platform-specific data to each frame.  This is the most straightforward way to
> > > add per-frame metadata without otherwise affecting UVC functionality.  We have
> > > used this method successfully on Linux (using the 0-format hack) and on
> > > Windows, where it required a registry configuration but was otherwise
> > > supported.
> >
> > To support that device on Linux, the right way is to define a meta
> > format (such as V4L2_META_FMT_UVC and V4L2_META_FMT_UVC_MSXU_1_5) and
> > either add a VID:PID entry to the driver's uvc_ids[] array if the number
> > of devices is small, or define an XU that advertises support for the
> > format if you expect a larger number of devices. The metadata format
> > needs to be documented.
> 
> I understand the device-specific metadata approach via uvc_ids. However, my
> device is an internal development platform not intended for public
> availability, so adding specific support for it in the kernel would not be
> appropriate.
> 
> Would it be reasonable to consider a generic metadata format (such as
> V4L2_META_FMT_UVC_RAW/EXT) that could be used with generic devices? This could
> be a useful feature for UVC device development and testing in general.

The reason for the current design is to ensure that metadata formats get
publicly documented. A generic format would defeat that.

-- 
Regards,

Laurent Pinchart

Re: uvcvideo regression: loss of access to full UVC payload header for generic UVC devices since 6.17

[Ricardo Ribalda]

Hi Itay

On Thu, 19 Feb 2026 at 10:16, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> On Thu, Feb 19, 2026 at 09:01:15AM +0000, Itay Perl wrote:
> > On 19 February 2026 16:21, Laurent Pinchart wrote:
> > > On Thu, Feb 19, 2026 at 06:03:49AM +0000, Itay Perl wrote:
> > > > ON 19 February 2026 06:22, Laurent Pinchart wrote:
> > > > > On Wed, Feb 18, 2026 at 11:56:28AM +0000, Itay Perl wrote:
> > > > > > On 18 February 2026 19:17, Ricardo Ribalda wrote:
> > > > > > > On Wed, 18 Feb 2026 at 11:59, Itay Perl wrote:
> > > > > > > > Would restoring the previous behavior be acceptable for compatibility?
> > > > > > > > Alternatively (or additionally), would it make sense to introduce a dedicated
> > > > > > > > metadata format that allows userspace to request the full UVC header for
> > > > > > > > generic devices?
> > > > > > >
> > > > > > > By any chance the device that you are using supports
> > > > > > > V4L2_META_FMT_UVC_MSXU_1_5 ?
> > > > > > > If the device exposes the UVC_MSXU_CONTROL_METADATA control, that
> > > > > > > format should be available, and it provices access to all the UVC
> > > > > > > header as you had before.
> > > > > > >
> > > > > > > Alternatively, if this is needed for a specific device you could send
> > > > > > > a patch adding the UVC_QUIRK_MSXU_META for that device.
> > > > > > > Would that work for you?
> > > > > >
> > > > > > My device is an internal development platform and does not have a public VID/PID
> > > > > > that could reasonably be added to the driver.
> > > > > >
> > > > > > I may be able to implement the MSXU control on the device side as a workaround,
> > > > > > but I'm concerned that this could cause issues when the device is used on a
> > > > > > Windows machine, which may expect the UVC header to follow a certain
> > > > > > format when MSXU is present.
> > > > >
> > > > > Does your device implement a vendor-specific metadata format ?
> > > >
> > > > Yes, the device uses a vendor-specific metadata format to attach
> > > > platform-specific data to each frame.  This is the most straightforward way to
> > > > add per-frame metadata without otherwise affecting UVC functionality.  We have
> > > > used this method successfully on Linux (using the 0-format hack) and on
> > > > Windows, where it required a registry configuration but was otherwise
> > > > supported.
> > >
> > > To support that device on Linux, the right way is to define a meta
> > > format (such as V4L2_META_FMT_UVC and V4L2_META_FMT_UVC_MSXU_1_5) and
> > > either add a VID:PID entry to the driver's uvc_ids[] array if the number
> > > of devices is small, or define an XU that advertises support for the
> > > format if you expect a larger number of devices. The metadata format
> > > needs to be documented.
> >
> > I understand the device-specific metadata approach via uvc_ids. However, my
> > device is an internal development platform not intended for public
> > availability, so adding specific support for it in the kernel would not be
> > appropriate.
> >
> > Would it be reasonable to consider a generic metadata format (such as
> > V4L2_META_FMT_UVC_RAW/EXT) that could be used with generic devices? This could
> > be a useful feature for UVC device development and testing in general.
>
> The reason for the current design is to ensure that metadata formats get
> publicly documented. A generic format would defeat that.

If you plan to release a device with a proprietary metada the easiest
way fwd would be create a new new format (as Laurent suggested).

During the development phase you can use a quirk to force
V4L2_META_FMT_UVC_MSXU_1_5 in your device. Something like:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/media/usb/uvc/uvcvideo.h#n83

rmmod uvcvideo
modprobe uvcvideo quirks=0x00040000

Btw, If you have the chance, I'd recommend going with the
V4L2_META_FMT_UVC_MSXU_1_5 format. It is quite flexible and the driver
already supports it, there's no reason to re-invent the wheel if you
can avoid it.

Regards!
>
> --
> Regards,
>
> Laurent Pinchart



-- 
Ricardo Ribalda