4L2 color space / swapped colors bug on Raspberry Pi 3B (Kernel 6.6+) with USB Grabbers (MS2130)

[thomas126]

Describe the bug

Describe the bug

There is a persistent bug in the V4L2 subsystem on older Raspberry Pi models (specifically Raspberry Pi 3B and Zero 2W) since the transition to Kernel 6.6. When capturing video via a standard USB HDMI grabber (like the MacroSilicon MS2130), the colors are processed incorrectly or completely swapped (inverted look), while the identical setup works flawlessly on Raspberry Pi 4/5 or with older Kernel 6.1.

This issue has been deeply analyzed in the HyperHDR community (Reference: awawa-dev/HyperHDR#848).

Using the command:
v4l2-ctl -d /dev/video0 --set-ctrl=brightness=50

sometimes temporarily resets the colors, but it is not persistent and breaks during modern color-space shifting (like HDR-to-SDR tone mapping).

Hardware

• Raspberry Pi 3 Model B
• USB HDMI Capture Card (MacroSilicon MS2130 / MS2109)

Steps to reproduce the behaviour

Steps to reproduce

1. Connect an MS2130 HDMI grabber to a Raspberry Pi 3B running Bookworm (Kernel 6.6).
2. Capture a video stream using HyperHDR or any standard V4L2 grabber software.
3. Observe the inverted/swapped color output on the video pipeline processed for external hardware LEDs.

Device (s)

Raspberry Pi 3 Mod. B, Raspberry Pi 3 Mod. B+

System

OS / Kernel version

• Raspberry Pi OS (Bookworm)
• Kernel version: 6.6.x (or newer)

Logs

No response

Additional context

No response

[6by9]

Almost all USB video capture devices use the UVC (USB Video Class) driver uvcvideo.
The Raspberry Pi kernel has no modifications to that driver compared to the mainline kernel.

Looking at your linked thread, awawa-dev/HyperHDR#848 (comment)

kernel-6.6.x:
...
User Controls
brightness 0x00980900 (int) : min=0 max=100 step=1 default=-8193 value=0
contrast 0x00980901 (int) : min=0 max=100 step=1 default=57343 value=100
saturation 0x00980902 (int) : min=0 max=100 step=1 default=57343 value=100
hue 0x00980903 (int) : min=0 max=100 step=1 default=-8193 value=0
---end output---

So I tried to setup the "User-Controls" Manually with: "v4l2-ctl --set-ctrl=brightness=50 --set-ctrl=contrast=50 --set-ctrl=saturation=50 --set-ctrl=hue=50"; like Kernel 6.1.x

All the control ranges and default values are read from the standard UVC device descriptors. There's nothing special in the USB stack for that at all. It also shouldn't be possible to initial a V4L2 control via the normal mechanisms where the default is out of the range defined via min and max. The value has just been clipped to either min or max depending on which extreme the value was on.

You can try adding uvcvideo.trace=0xfff to the start of the line in /boot/firmware/cmdline.txt (do NOT add any carriage returns) to enable loads of additional tracing within the driver and reboot. Then post the output from the kernel log (reported via dmesg).

MS2109 is a USB2 device. MS2130 is a USB3 device. They will behave very differently as neither Pi3 nor Pi02 support USB3.
So which one are you actually looking at?
I'm going to suspect MS2130 due to the report of it working with Pi4 (which does support USB3).

[P33M]

The uvcvideo control bug was fixed in #3150 but only applies to dwc_otg. In practice, it's benign as the corrupt defaults are ignored and correctly clamped values are used, as @6by9 says.

Please confirm which kernel version is in use from uname -a, and post the full contents of dmesg in the failing case.

[6by9]

In practice, it's benign as the corrupt defaults are ignored and correctly clamped values are used, as @6by9 says.

They're clamped, but that doesn't give a terribly helpful value as most of them want the midpoint.

#3150 feels a long time ago (2019) for something that was OK in 6.1 but not in 6.6, unless we have a regression there.