New: uvcvideo: Realtek Integrated_Webcam_HD (0bda:5696) RGB sensor never delivers frame data after STREAMON
https://bugzilla.kernel.org/show_bug.cgi?id=221963
Bug ID: 221963
Summary: uvcvideo: Realtek Integrated_Webcam_HD (0bda:5696) RGB
sensor never delivers frame data after STREAMON
Product: Drivers
Version: 2.5
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: USB
Assignee: [email protected]
Reporter: [email protected]
Regression: NoCreated attachment 310780
--> https://bugzilla.kernel.org/attachment.cgi?id=310780&action=edit
Open the file I made (uvcvideo_bug_report.md), copy everything from "## Summary" onward, and paste it into the description box.
Open the file I made (uvcvideo_bug_report.md), copy everything from "## Summary" onward, and paste it into the description box.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221963] uvcvideo: Realtek Integrated_Webcam_HD (0bda:5696) RGB sensor never delivers frame data after STREAMON
https://bugzilla.kernel.org/show_bug.cgi?id=221963
--- Comment #1 from Chandra Joshi ([email protected]) ---
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: okVIDIOC_REQBUFS returned 0 (Success)VIDIOC_QUERYBUF returned 0 (Success) x4VIDIOC_G_FMT returned 0 (Success)VIDIOC_QBUF returned 0 (Success) x4VIDIOC_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.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221963] uvcvideo: Realtek Integrated_Webcam_HD (0bda:5696) RGB sensor never delivers frame data after STREAMON
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221963
Michał Pecio ([email protected]) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]
--- Comment #2 from Michał Pecio ([email protected]) --- (In reply to Chandra Joshi from comment #0)
Quoted 3 lines
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)
Quoted 9 lines
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 ... =0c8c00000000eab586008a0200000000...
Quoted 3 lines
(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.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.