## Summary Integrated webcam (Chicony 04f2:b6cb) on Lenovo Yoga Slim 7 Pro 14IHU5 (model 82NC) enumerates correctly, negotiates UVC formats, and streams isochronous packets with zero USB errors — but every video payload contains only the 12-byte UVC stream header and **no pixel data**. Camera indicator LED turns on, ealthy, but no application (ffmpeg, v4l2-ctl rawstream capture, Chrome/Google Meet, Zoom) ever receives a usable frame. This is a regression: the camera worked normally undeUbuntu 22.04 on this same machine, before upgradin ## System - Laptop: Lenovo Yoga Slim 7 Pro 14IHU5, system model 82NC, BIOS FJCN69WW - OS: Ubuntu 24.04.4 LTS (previously worked fine o) - Kernels tested: 6.8.0-137-generic (GA) and 6.14.0-37-generic (HWE) — **identical failure on both**, confirmed with matched usbmon captures on each (see below). This rules ouegression between 6.8 and 6.14; the break happenedsomewhere between 22.04's kernel/driver stack and 24.04's. - Camera: Chicony Electronics Integrated Camera, U bcdDevice 80.18 - Composite device: RGB sensor on interface 0/1 (UVC 1.10, /dev/video0-1), separate IR sensor on interface 2/3 (UVC 1.50, /dev/video2-3, used for Windows Hello / face auth format-negotiation failure, not the focus of thisreport) - Camera exposes 3 vendor Extension Units (XUs) r, which are typically used by the OEM Windowsdriver to perform proprietary sensor init: - XU 4: guid {1229a78c-47b4-4094-b0ce-db07386f - XU 7: guid {26b8105a-0713-4870-979d-da79444bb68e} - XU 8: guid {0f3f95dc-2632-4c4e-92c9-a04782f4 ## Possible IPU6 connection This machine also has an Intel IPU6 MIPI camera stack path available (`linux-modules-ipu6-generic-hwe-24.04` / `linux-modules-ipu6-6.14.0-37-generic` packages exring earlier troubleshooting the reporter installed and then removed/purged these IPU6 packages, without effect on the UVC camera's frame delivery either way (tested with them absent). It's possible the working 22.04 setup relr-init path (or an older `uvcvideo` with adevice-specific quirk/XU sequence) that isn't present in 24.04's stack — worth checking whether `linux-modules-ipu6-generic-hwe-24.04` (properly is the behavior, though it was not observed to helpin this case. Separately, and not the cause of the camera bug itself: removing the IPU6 packages had an unrelated destructive side effect — `linux-modules-extra-6.14.0-37-generic` (containinGPU/other drivers) was left uninstalled, breakingWiFi, touchpad, and display scaling specifically on 6.14 until reinstalled. That has been resolved and is mentioned only for completeness/context. ## Steps to reproduce v4l2-ctl -d /dev/video0 --set-fmt-video=width=640,height=480,pixelformat=YUYV --stream-mmap --stream-count=5 --stream-to=/tmp/ Result: hangs until interrupted; output file is 0 bytes. Same result via `ffmpeg -f v4l2 -i /dev/video0 ...` (both `mjpeg` and `yuyv422` input formats): ffmpeg opens the device,iption, but gets EOF with no decodable frame.Identical result on both 6.8.0-137-generic and 6.14.0-37-generic. ## Evidence: usbmon capture during a stream attempt Captured via `/sys/kernel/debug/usb/usbmon/3u` whioth kernels. USB control-plane traffic (formatprobe/commit, altsetting select) completes normally. Isochronous IN completions on endpoint 1 look like this, repeated for theentire capture with no errors, on **both** kernel C Zi:3:002:1 0:1:15352:0 32 0:0:12 0:2940:12 0:5880:12 0:8820:12 0:11760:12 94080 = 0c8c0000 000075c3 9f017d07 00000000... Every isochronous packet descriptor completes withual_length=12 bytes** — exactly the size of a bareUVC payload header (FID/EOF/PTS/SCR fields) with zero image bytes following it. This pattern is consistent across hundreds of isochronous packets captured on each kernel; no URcol errors anywhere in dmesg on either kernel. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2163506 Title: Integrated webcam (Chicony 04f2:b6cb) on Lenovo Yoga Slim 7 Pro 14IHU5 (model 82NC) doesnt work after upgrading to Ubuntu 24.04 Status in linux package in Ubuntu: New Bug description: ## Summary Integrated webcam (Chicony 04f2:b6cb) on Lenovo Yoga Slim 7 Pro 14IHU5 (model 82NC) enumerates correctly, negotiates UVC formats, and streams isochronous packets with zero USB errors — but every video payload contains only the 12-byte UVC stream header and **no pixel data**. Camera indicator LED turns on, USB traffic looks nominally healthy, but no application (ffmpeg, v4l2-ctl raw stream capture, Chrome/Google Meet, Zoom) ever receives a usable frame. This is a regression: the camera worked normally before upgrading this machine from Ubuntu 22.04 to 24.04. ## System - Laptop: Lenovo Yoga Slim 7 Pro 14IHU5, system model 82NC, BIOS FJCN69WW - OS: Ubuntu 24.04.4 LTS - Kernels tested: 6.8.0-137-generic (GA) and 6.14.0-37-generic (HWE) — **both affected** - Camera: Chicony Electronics Integrated Camera, USB ID 04f2:b6cb, bcdUVC 1.10, bcdDevice 80.18 - Composite device: RGB sensor on interface 0/1 (UVC 1.10, /dev/video0-1), separate IR sensor on interface 2/3 (UVC 1.50, /dev/video2-3, used for Windows Hello / face auth — reproduces its own distinct format-negotiation failure, not the focus of this report) - Camera exposes 3 vendor Extension Units (XUs) in its VideoControl descriptor, which are typically used by the OEM Windows driver to perform proprietary sensor init: - XU 4: guid {1229a78c-47b4-4094-b0ce-db07386fb938} - XU 7: guid {26b8105a-0713-4870-979d-da79444bb68e} - XU 8: guid {0f3f95dc-2632-4c4e-92c9-a04782f43bc8} ## Steps to reproduce ``` v4l2-ctl -d /dev/video0 --set-fmt-video=width=640,height=480,pixelformat=YUYV \ --stream-mmap --stream-count=5 --stream-to=/tmp/raw_test.yuv ``` Result: hangs until interrupted; output file is 0 bytes. Same result via `ffmpeg -f v4l2 -i /dev/video0 ...` (both `mjpeg` and `yuyv422` input formats): ffmpeg opens the device, receives format/stream description, but gets EOF with no decodable frame. ## Evidence: usbmon capture during a stream attempt Captured via `/sys/kernel/debug/usb/usbmon/3u` while streaming was active. USB control-plane traffic (format probe/commit, altsetting select) completes normally. Isochronous IN completions on endpoint 1 look like this, repeated for the entire capture with no errors: ``` C Zi:3:002:1 0:1:15352:0 32 0:0:12 0:2940:12 0:5880:12 0:8820:12 0:11760:12 94080 = 0c8c0000 000075c3 9f017d07 00000000... ``` Every isochronous packet descriptor completes with status 0 (success) but **actual_length=12 bytes** — exactly the size of a bare UVC payload header (FID/EOF/PTS/SCR fields) with zero image bytes following it. This pattern is consistent across ~475 isochronous packets captured; no URB errors, no babble, no protocol errors anywhere in dmesg. ## What's been ruled out - USB autosuspend (device was suspending; disabling via udev `power/control=on` fixed an earlier separate symptom — the browser's "camera not found" error disappeared once the device reliably stays powered — but did not fix frame delivery) - `uvcvideo quirks=128` (UVC_QUIRK_FIX_BANDWIDTH) — no effect - `power_line_frequency` control (known bug class on other Lenovo-integrated cameras, see kernel patch "media: uvcvideo: Fix power line control for Lenovo Integrated Camera" for Shine-Optics 3277:009e) — set explicitly via v4l2-ctl, no effect - Lenovo EC camera-power gate (`/sys/devices/pci0000:00/0000:00:1f.0/PNP0C09:00/VPC2004:00/camera_power`) — toggled off/on, no effect, reads `1` (enabled) - No physical privacy shutter on this model; no dedicated Fn camera-toggle hotkey found - No pending firmware updates for "Integrated Camera" via fwupd/LVFS - Fresh `modprobe -r uvcvideo && modprobe uvcvideo` before each test to rule out stale driver state - GNOME camera privacy toggle off (not blocking), correct udev ACL for /dev/video0, no other process holding the device open, no `/etc/modprobe.d` blacklist affecting uvcvideo/i2c_hid/psmouse ## Working theory The three vendor Extension Units suggest the OEM Windows driver performs a proprietary init/wake sequence on the sensor via one of these XUs before it will actually output pixel data. `uvcvideo`'s generic UVC negotiation (probe/commit/altsetting) succeeds because that part of the protocol is standard, but without the correct XU command sequence the sensor silently stays in a "streaming but dark" state — it acknowledges the stream request and sends header-only payloads, but never activates actual pixel readout. Since this camera reportedly worked under this same laptop before upgrading Ubuntu 22.04 → 24.04, something changed (kernel version, uvcvideo driver behavior, or firmware quirk table) between the two setups; a bisect against the 22.04 kernel/driver version would help narrow this down further. ## Requested - Guidance on whether a uvcvideo quirk/XU-init patch is feasible for this device, similar to the existing "Fix power line control for Lenovo Integrated Camera" precedent - Any pointers to existing bug reports for Chicony 04f2:b6cb or Lenovo model 82NC camera issues ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-image-6.8.0-137-generic 6.8.0-137.137 ProcVersionSignature: Ubuntu 6.8.0-137.137-generic 6.8.12 Uname: Linux 6.8.0-137-generic x86_64 NonfreeKernelModules: zfs ApportVersion: 2.28.3-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: raghu 3845 F.... pipewire raghu 3849 F.... wireplumber /dev/snd/seq: raghu 3845 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Aug 14 20:28:25 2026 HibernationDevice: RESUME=none InstallationDate: Installed on 2023-05-23 (1179 days ago) InstallationMedia: Ubuntu 22.04.2 LTS "Jammy Jellyfish" - Release amd64 (20230223) MachineType: LENOVO 82NC ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/BOOT/ubuntu_px4ncd@/vmlinuz-6.8.0-137-generic root=ZFS=rpool/ROOT/ubuntu_px4ncd ro quiet splash i8042.direct i8042.dumbkbd RelatedPackageVersions: linux-restricted-modules-6.8.0-137-generic N/A linux-backports-modules-6.8.0-137-generic N/A linux-firmware 20240318.git3b128b60-0ubuntu2.29 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/21/2022 dmi.bios.release: 1.69 dmi.bios.vendor: LENOVO dmi.bios.version: FJCN69WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0T76485 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Yoga Slim 7 Pro 14IHU5 dmi.ec.firmware.release: 1.31 dmi.modalias: dmi:bvnLENOVO:bvrFJCN69WW:bd03/21/2022:br1.69:efr1.31:svnLENOVO:pn82NC:pvrYogaSlim7Pro14IHU5:rvnLENOVO:rnLNVNB161216:rvrSDK0T76485WIN:cvnLENOVO:ct10:cvrYogaSlim7Pro14IHU5:skuLENOVO_MT_82NC_BU_idea_FM_YogaSlim7Pro14IHU5: dmi.product.family: Yoga Slim 7 Pro 14IHU5 dmi.product.name: 82NC dmi.product.sku: LENOVO_MT_82NC_BU_idea_FM_Yoga Slim 7 Pro 14IHU5 dmi.product.version: Yoga Slim 7 Pro 14IHU5 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2163506/+subscriptions
Комментариев нет:
Отправить комментарий