[Bug 221963] uvcvideo: Realtek Integrated_Webcam_HD (0bda:5696) RGB sensor never delivers frame data after STREAMON

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=221963

--- Comment #1 from Chandra Joshi (cj897048@gmail.com) ---
On a laptop with a Realtek "Integrated_Webcam_HD" combo RGB+IR webcam module
(USB ID 0bda:5696), the RGB capture node (/dev/video0) accepts VIDIOC_STREAMON
successfully and negotiates valid formats (YUYV and MJPG, multiple
resolutions), but never delivers a single video frame. The call hangs
indefinitely until killed. No error, warning, or informational message is
logged to the kernel ring buffer during the hang — dmesg is completely silent.

The companion IR node (/dev/video2, 340x374, monochrome) on the same physical
USB device streams frames successfully and immediately.

Hardware / environment
Webcam: Realtek Integrated_Webcam_HD, USB ID 0bda:5696
USB topology: dedicated port, not sharing a hub with other devices (lsusb -t
shows Port 005, all 4 interfaces belong solely to this device)
Device exposes 4 nodes: /dev/video0, /dev/video1, /dev/video2, /dev/video3
(video0 and video2 are the only ones with usable capture formats)
Distro: Ubuntu 24.04 (Noble)
Kernel tested: 7.0.0-30-generic and 7.0.0-31-generic (HWE) — identical behavior
on both
No dual-boot Windows available to confirm hardware-level functionality (a
stale/unused Windows Boot Manager EFI entry exists but no working Windows
installation is present)
Steps to reproduce
v4l2-ctl -d /dev/video0 --stream-mmap --stream-count=5 --verbose

Result:

VIDIOC_QUERYCAP: ok
VIDIOC_REQBUFS returned 0 (Success)
VIDIOC_QUERYBUF returned 0 (Success)   x4
VIDIOC_G_FMT returned 0 (Success)
VIDIOC_QBUF returned 0 (Success)       x4
VIDIOC_STREAMON returned 0 (Success)
<hangs forever, no further output, no DQBUF ever completes>

Equivalent hang reproduced independently with:

ffmpeg -f v4l2 -i /dev/video0 -frames:v 1 out.jpg
ffmpeg -f v4l2 -input_format mjpeg -video_size 640x480 -i /dev/video0 -frames:v
1 out.jpg
ffplay -f v4l2 -video_size 1280x720 -i /dev/video0
cheese (GStreamer backend)

All fail identically: format negotiates, STREAMON-equivalent succeeds, zero
packets/frames ever arrive.

Formats/controls confirmed valid (ruling out a format problem)
v4l2-ctl -d /dev/video0 --list-formats-ext
        [0]: 'MJPG' - 640x480, 1280x720, 960x540, 848x480, 640x360 @ 30fps
        [1]: 'YUYV' - 640x480, 640x360, 424x240, 320x240, 320x180, 160x120 @
30fps

v4l2-ctl -d /dev/video0 --list-ctrls
        brightness=0 (default 0), contrast=8, saturation=64 (default),
        gain=1 (min), auto_exposure=Aperture Priority (default),
        exposure_time_absolute=156 (default 156, inactive/auto)
        -> all values are sane defaults, not stuck at an extreme
Things ruled out during troubleshooting
Pixel format mismatch — tested both YUYV and MJPG explicitly, both hang
identically.
Exposure/brightness stuck low — control values are default/sane, not at min.
USB autosuspend — disabled via echo on >
/sys/bus/usb/devices/1-5/power/control; no change.
uvcvideo bandwidth quirk — reloaded driver with modprobe uvcvideo quirks=128
(UVC_QUIRK_FIX_BANDWIDTH); no change.
USB hub/bandwidth sharing with sibling devices — lsusb -t shows the webcam
alone on its own port; nothing else shares it.
Stale/cached kernel state — full USB-level unbind/bind cycle performed: echo
1-5 > /sys/bus/usb/drivers/usb/unbind then .../bind; device re-enumerates
cleanly (all 4 /dev/video* nodes return, uvcvideo re-attaches) but /dev/video0
still hangs identically afterward.
Outdated kernel — upgraded from 7.0.0-30-generic to 7.0.0-31-generic (latest
available HWE kernel at time of testing); identical hang before and after,
including a full reboot.
Driver crash / GStreamer-specific bug — reproduced the same zero-frame hang
with ffmpeg and raw v4l2-ctl --stream-mmap directly, bypassing GStreamer/cheese
entirely, so this is not an application-layer bug.
Physical privacy shutter — laptop has no hardware camera shutter or Fn-key
camera toggle.
UVC_QUIRK_STREAM_NO_FID (quirks=16) — no change; see usbmon finding below for
why.
dmesg during the hang

Completely silent — no uvcvideo messages, no USB errors (no "usb_set_interface
failed", no "isochronous frame lost", no timeout/reset events), nothing at all
correlated with the hang window.

usbmon capture — key finding

A 10-second usbmon capture (bus 1, isochronous endpoint 1 of the webcam,
/sys/kernel/debug/usb/usbmon/1u) was taken while running v4l2-ctl -d
/dev/video0 --stream-mmap --stream-count=3 --verbose.

Findings:

Isochronous transfers on Ii:1:004:1 complete successfully (status 0),
confirming USB-level data transfer genuinely occurs — this is not a
transport/bandwidth failure.
However, every single isochronous packet returned across the entire 10-second
capture has payload length exactly 12 bytes — i.e. only the bare UVC payload
header, with zero pixel data ever included:
C Zi:1:004:1 0:1:5224:0 32 0:0:12 0:2814:12 0:5628:12 ... = 0c8c0000 0000eab5
86008a02 00000000...

(0c = header length 12; 8c = bmHeaderInfo, decodes to EOH=1, SCR=1, PTS=1,
FID=0, EOF=0 — both FID and EOF remain constant/unset for the entire capture,
consistent with zero frame boundaries ever being signaled)

This pattern is identical and unchanging for the full duration of the capture —
the sensor never once includes actual image payload bytes, only the 12-byte
header, packet after packet.
Interpretation

Given this, the issue is not a uvcvideo driver bug in interpreting frame
boundaries or payload — the RGB sensor's ISP/pixel pipeline itself appears to
never produce or transmit actual image data, despite the control plane (format
negotiation, STREAMON, isochronous transport) functioning perfectly. This
strongly suggests either a hardware fault in the RGB sensor, or a missing
vendor-specific initialization/power-on sequence that the Windows driver sends
but that uvcvideo's device quirk table does not replicate for this device ID.

Request
Has anyone reported this specific behavior for 0bda:5696?
Is there a known vendor-specific control sequence / quirk that could be added
for this device ID?
Any additional trace-level diagnostics (e.g. usbmon, UVC control transfers via
usbmon/wireshark-usb) that would help pin down whether the sensor is being sent
a wake/power command at all?

Happy to gather additional usbmon captures or test patches — I have full shell
access to the affected hardware.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.