* [Bug 221963] uvcvideo: Realtek Integrated_Webcam_HD (0bda:5696) RGB sensor never delivers frame data after STREAMON
2026-09-04 6:45 [Bug 221963] New: uvcvideo: Realtek Integrated_Webcam_HD (0bda:5696) RGB sensor never delivers frame data after STREAMON bugzilla-daemon
@ 2026-09-04 7:03 ` bugzilla-daemon
2026-09-04 9:04 ` bugzilla-daemon
1 sibling, 0 replies; 3+ messages in thread
From: bugzilla-daemon @ 2026-09-04 7:03 UTC (permalink / raw)
To: linux-usb
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.
^ permalink raw reply [flat|nested] 3+ messages in thread* [Bug 221963] uvcvideo: Realtek Integrated_Webcam_HD (0bda:5696) RGB sensor never delivers frame data after STREAMON
2026-09-04 6:45 [Bug 221963] New: uvcvideo: Realtek Integrated_Webcam_HD (0bda:5696) RGB sensor never delivers frame data after STREAMON bugzilla-daemon
2026-09-04 7:03 ` [Bug 221963] " bugzilla-daemon
@ 2026-09-04 9:04 ` bugzilla-daemon
1 sibling, 0 replies; 3+ messages in thread
From: bugzilla-daemon @ 2026-09-04 9:04 UTC (permalink / raw)
To: linux-usb
https://bugzilla.kernel.org/show_bug.cgi?id=221963
Michał Pecio (michal.pecio@gmail.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |michal.pecio@gmail.com
--- Comment #2 from Michał Pecio (michal.pecio@gmail.com) ---
(In reply to Chandra Joshi from comment #0)
> Created attachment 310780 [details]
> Open the file I made (uvcvideo_bug_report.md), copy everything from "##
> Summary" onward, and paste it into the description box.
I would rather not do that :)
(In reply to Chandra Joshi from comment #1)
> 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)
Do these 12 byte packets keep flowing forever until user application is turned
off, or do they stop unexpectedly at some earlier time?
If this is truly a problem with the camera or UVC driver, not with USB itself,
then you have reported it in the wrong place. Follow instructions here
https://docs.kernel.org/admin-guide/reporting-issues.html
and email uvcvideo maintainers with linux-media in Cc.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 3+ messages in thread