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

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

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