Fedora Account System
Red Hat Associate
Red Hat Customer
1. Please describe the problem: The camera device is not available on Thinkpad X1 Carbon Gen14. I can't even see the device: $ lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 002: ID 1050:0403 Yubico.com Yubikey 4/5 OTP+U2F Bus 003 Device 003: ID 06cb:019f Synaptics, Inc. Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub $ ls -l /dev/video* ls: cannot access '/dev/video*': No such file or directory There might multiple versions of Thinkpad X1 Carbon Gen14 laptops, so this might be a MIPI camera issue on this particular version. Further investigation required. 2. What is the Version-Release number of the kernel: kernel-7.0.10-200.fc44.x86_64 Firmware versions: UEFI version: N4OET47W (1.10 ) 03/30/2026 System version: N4OSG16W (1.16) EC version: N4OHT37W (1.07) ME version: 21.0.2.1482 Machine type model: 21V8ZDJLUS 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : No 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Run snapshot or other camera app, "no camera found". Running google meet in Firefox shows the same issue. 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: Yes. Tested with kernel-7.1.0-0.rc5.260527geb3f4b7426cf.37.fc45.x86_64 . 6. Are you running any modules that not shipped with directly Fedora's kernel?: No 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag.
Created attachment 2143329 [details] kernel log
Created attachment 2143330 [details] full system journal
CC @mpearson
Hi @kparal I found this in the dmesg May 29 10:39:26 chronos kernel: intel_ipu7: module is from the staging directory, the quality is unknown, you have been warned. May 29 10:39:26 chronos kernel: intel-ipu7 0000:00:05.0: enabling device (0000 -> 0002) May 29 10:39:26 chronos kernel: intel-ipu7 0000:00:05.0: Device 0xb05d (rev: 0x8) May 29 10:39:26 chronos kernel: intel-ipu7 0000:00:05.0: IPU7 PCI BAR0 base 0x000000806e000000 BAR2 base 0x000000807136c000 May 29 10:39:26 chronos kernel: intel-ipu7 0000:00:05.0: IPU7 PCI BAR0 mapped at 00000000ae7cdced BAR2 mapped at 0000000074402231 May 29 10:39:26 chronos kernel: intel-ipu7 0000:00:05.0: IPU7 SKU 1 in secure mode mask 0x0 May 29 10:39:26 chronos kernel: intel-ipu7 0000:00:05.0: firmware cpd file: intel/ipu/ipu7ptl_fw.bin May 29 10:39:26 chronos kernel: intel-ipu7 0000:00:05.0: Direct firmware load for intel/ipu/ipu7ptl_fw.bin failed with error -2 May 29 10:39:26 chronos kernel: intel-ipu7 0000:00:05.0: error -ENOENT: Requesting signed firmware intel/ipu/ipu7ptl_fw.bin failed May 29 10:39:26 chronos kernel: intel-ipu7 0000:00:05.0: probe with driver intel-ipu7 failed with error -2 The driver failed to load the firmware. Could you please verify the "intel-vsc-firmware" package is installed? It also needs the libcamera package :) Thank you
Thanks, Kate. intel-vsc-firmware was not installed indeed (it doesn't seem to be a part of a default install, should it get auto-installed somehow?). Once I install it (intel-vsc-firmware-20260519-1.fc44.noarch), the video devices exist and Snapshot starts correctly. Unfortunately, all I see is a black screen. The journal prints these: Jun 01 13:54:49 chronos pipewire[2287]: spa.v4l2: /dev/video0: VIDIOC_S_PARM: Inappropriate ioctl for device Jun 01 13:54:49 chronos pipewire[2287]: spa.v4l2: '/dev/video0' VIDIOC_STREAMON: Link has been severed Jun 01 13:54:49 chronos pipewire[2287]: pw.node: (v4l2_input.pci-0000_00_05.0-115) suspended -> error (Start error: Link has been severed) Jun 01 13:54:49 chronos pipewire[2287]: spa.v4l2: '/dev/video0' VIDIOC_STREAMON: Link has been severed Jun 01 13:54:54 chronos pipewire[2287]: spa.v4l2: /dev/video0: VIDIOC_S_PARM: Inappropriate ioctl for device Jun 01 13:54:54 chronos pipewire[2287]: spa.v4l2: '/dev/video0' VIDIOC_STREAMON: Link has been severed Jun 01 13:54:54 chronos pipewire[2287]: pw.node: (v4l2_input.pci-0000_00_05.0-115) suspended -> error (Start error: Link has been severed)
Created attachment 2143718 [details] journal-with-intel-vsc-firmware.txt
Hi, Can you use libcamera-qcam to verify the video? If you can see the video, that means ipu7 and libcamera work properly. 1. install libcamera-qcam with "dnf install libcamera-qcam" 2. Run "qcam" in the console and you can see the qcam window pop up. Additionally, could you please list the device ID in the /sys/bus/acpi/devices and the device in the /sys/bus/i2c/devices?
Unfortuntely libcamera-qcam shows a small window where no camera can be selected, the drop-down list is completely empty. It prints: $ qcam [0:04:12.685607086] [6893] INFO Camera camera_manager.cpp:340 libcamera v0.7.1 [0:04:12.704262906] [6906] INFO SimplePipeline simple.cpp:1899 No sensor found for /dev/media0 No camera detected Will attach the devices outputs.
Created attachment 2143944 [details] acpi-devices.txt
Created attachment 2143945 [details] i2c-devices.txt
I found TBE20A0:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/TBE20A0:00 (ACPI) and i2c-TBE20A0:00 -> ../../../devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-TBE20A0:00 (i2c bus) It shows an IMX471 sensor was on your laptop but the driver hasn't been upstreamed yet. I'm working on it and the patch set can be found https://lore.kernel.org/linux-media/20260505061327.286700-1-hpa@redhat.com/ One solution is to wait for it upstream. In the meantime, you can help test this patch. Another workaround is to install the ipu6 driver in the RPMFusion. The imx471 driver is in the ip6-drivers 1. enable RPMFusion (both free and nonfree) https://rpmfusion.org/Configuration 2. install ipu6-drivers $ sudo dnf install ipu6-camera-bins If you can see the video via qcam, please let me know :) I'll add the APCI ID (TBE20A0) to my upstream patch set.
I'll be able to test it later today or tomorrow. In the meantime, could you please create a scratch build in Koji with your patch included? Thank you.
Hi Kamil, I updated the driver and the ACPI ID to the Fedora kernel and it can be found at the following URL https://koji.fedoraproject.org/koji/taskinfo?taskID=146231113 (You can download it after the building process completes)
With this kernel, the camera starts working. However, there are a few problems: 1. The image is flipped horizontally (I'm upside down), both in qcam and snapshot. 2. The image is flipped vertically in snapshot, but not in qcam. The standard camera approach seems to display your right hand on the right side of the picture. This is what happens in qcam. But in snapshot, I see my right hand on the left side of the picture (which is technically correct, but is the opposite of what cameras seem to do). 3. The image shows temporary graphical artifacts (a colorful short lines) for moving objects. It's usable, but a little distracting. 4. Sometimes the image starts blinking heavily. It seems to be related to the amount of outside light. It seems it tries to calibrate, but instead it goes dark and bright several times per second. Moving the camera helps, e.g. to not see a window with bright light. But this is very inconvenient.
Created attachment 2144181 [details] journal with testing kernel Here's journal with the testing kernel. qcam is started in 17:02 (showing the issues described in the previous comment).
(In reply to Kamil Páral from comment #14) > With this kernel, the camera starts working. However, there are a few > problems: > > 1. The image is flipped horizontally (I'm upside down), both in qcam and > snapshot. Did you install ipu6-camera-bins package? If yes, please uninstall it and try it again. > 2. The image is flipped vertically in snapshot, but not in qcam. The > standard camera approach seems to display your right hand on the right side Perfect. What is the version of libcamera and Fedora? > of the picture. This is what happens in qcam. But in snapshot, I see my > right hand on the left side of the picture (which is technically correct, > but is the opposite of what cameras seem to do). > 3. The image shows temporary graphical artifacts (a colorful short lines) > for moving objects. It's usable, but a little distracting. This can be resolved by tuning the libcamera softISP algorithm after the driver is upstreamed. > 4. Sometimes the image starts blinking heavily. It seems to be related to > the amount of outside light. It seems it tries to calibrate, but instead it > goes dark and bright several times per second. Moving the camera helps, e.g. > to not see a window with bright light. But this is very inconvenient. This is the libcamera SoftISP 3A algorithm. They are improving this.
(In reply to Kate Hsuan from comment #16) > Did you install ipu6-camera-bins package? If yes, please uninstall it and > try it again. No, I only used your test kernel, no rmpfusion packages. > What is the version of libcamera and Fedora? libcamera-0.7.1-1.fc44.x86_64 Fedora 44 Also, while I didn't try rpmfusion's ipu6-camera-bins originally, I tried it now, with the official kernel-7.0.10-201.fc44.x86_64. I installed it, ran sudo akmods, rebooted into the same kernel, and it didn't have any effect. I still saw black screen in snapshot, "Inappropriate ioctl for device" and "Link has been severed" in journal, and no device in qcam. So I uninstalled everything again. Your kernel patch seems to be the only way to make it work (with the quirks mentioned).
Created attachment 2144293 [details] rpm -qa output
> The image is flipped horizontally (I'm upside down), both in qcam and snapshot. I wonder about the orientation of the image. Can you please upload an image snapshot using qcam? Thank you > Also, while I didn't try rpmfusion's ipu6-camera-bins originally, I tried it now, with the official kernel-7.0.10-201.fc44.x86_64. I installed it, ran sudo akmods, rebooted into the same kernel, and it didn't have any effect. I still saw black screen in snapshot, "Inappropriate ioctl for device" and "Link has been severed" in journal, and no device in qcam. So I uninstalled everything again. That means I have to update the package :P
Created attachment 2144295 [details] Camera orientation photo Here's my state of the art drawing to illustrate orientation
Thank you for you testing I dropped the orientation settings from ipu-bridge and made another test build. Can you please test this? https://koji.fedoraproject.org/koji/taskinfo?taskID=146378388
I uninstalled the previous kernel and installed the new one (because they have the same NVR), but there's no difference, the picture is still oriented exactly as before.
Can you please show the DMI BOARD_NAME? It can be found in /sys/class/dmi/id/board_name. It should be 21V7.... or 21V8.....
sorry! I made something wrong when building the test build. The orientation setting wasn't dropped when packaging it. Can you please test this again? https://koji.fedoraproject.org/koji/taskinfo?taskID=146423786 (without orientation setting in ipu-bridge) Thank you
If you could bump the NVR with each new test build (e.g. test2, test3, ...), that would be great even for me. Otherwise I spend extra time on reboots, because I can't install the builds next to each other. And I also did some mistakes, downloading the kernel from a wrong URL by accident, but not realizing it (my test results are still valid, just verifying them is time consuming due to the same NVR). (In reply to Kate Hsuan from comment #23) > Can you please show the DMI BOARD_NAME? It can be found in > /sys/class/dmi/id/board_name. > It should be 21V7.... or 21V8..... 21V8ZDJLUS (In reply to Kate Hsuan from comment #24) > https://koji.fedoraproject.org/koji/taskinfo?taskID=146423786 (without > orientation setting in ipu-bridge) Great, I'm no longer upside down :) A photo from qcam attached. In Snapshot, left and right is swapped compared to qcam, but as described before, it's probably intentional, because it feels more natural (like a mirror).
Created attachment 2144794 [details] Camera orientation photo (comment 24)
Perfect. qcam shows the raw image, and the snapshot mirrors it, so you will see different results from the two apps. The results showed that the image sensor was mounted with the correct orientation, so orientation settings can be removed from my patch. Mega thank you.
Thank you as well! I'd like to keep this bug open until this is fixed in Fedora packages, either through upstream kernel, or a local Fedora patch. We might need a separate bug for the brightness-related flickering issue. I don't know yet how frequent and inconvenient the issue is, I'd first need to use it more in real-world scenarios.
The flickering issue is related to the SoftISP 3A algorithm of libcamera. Please file a ticket against it. Thank you :)
Hi, I wanted to report that I have also a ThinkPad X1 Gen 14 and I’m experiencing the same issue: the webcam is detected, but only shows a black screen. Board name: 21V7CTO1WW ACPI devices: TBE20A0:00 TBE20A1:00 It seems you may have identified the root cause of the problem, thank you for that.
Julie, have you tried the test kernel from comment 24? Does it fix the problem for you?
I haven't tested it yet. As soon as I have some time, I'll give it a try. I may also wait for a future Fedora update that includes the fix, although I’m not sure how long it usually takes for such changes to make their way into a stable Fedora kernel.
Please test is soon, because the scratch build will get deleted in some days.
Hi, I tested the test kernel. The flickering is gone, I don't really see any artifacts (except maybe very briefly when camera initializes) and the horizontal/vertical looks fine. I have not installed the ipu6-camera-bins. Camera feed works on qcam and firefox i tested. On edge/chrome camera is not recognized unfortunately.
I managed to make it work on chromium based browsers by passing --enable-features=WebRtcPipeWireCamera. I am curious how long till the kernel makes it public?
Not sure. It is based on upstream reviewing bandwidth and my workload :) > I managed to make it work on chromium based browsers by passing --enable-features=WebRtcPipeWireCamera. You are right. MIPI solution needs pipewire + libcamera.
Hello, has this been pushed upstream? There is a new kernel but looks like the fix is not there yet
Hi, You can try to update the kernel to the latest 7.3.1 kernel through the following command. $ sudo dnf update kernel After updating the kernel, the camera should work. Here is the package IPU7 needs 1. intel-vsc-firmware 2. libcamera Ensure the package are installed before you start using the camera. :)
Sorry about the typo You can try to update the kernel to the latest *7.1.3* kernel through the following command. $ sudo dnf update kernel
Tested with official Fedora kernel 7.1.4-200.fc44, the camera works indeed, great. I believe we can close this bug now. Thanks a lot for your work, Kate.
I've created a follow-up for the colored horizontal lines visible in the video as bug 2502786. I didn't yet file a bug about the brightness flickering issue, because I didn't reproduce it today. Either it was fixed by some update, or I wasn't lucky enough today. It seems to need some specific lighting conditions to be triggered, and just moving the camera slightly can fix it, so it's quite hard to reproduce intentionally.
Confirmation from another SKU: the 2.8K OLED variant of the X1 Carbon Gen 14 (type 21V7CTO1WW, camera option "10MP RGB+IR with ToF") also has the **IMX471** behind ACPI `TBE20A0` — chip-verified, not inferred: with the sensor powered we read CCS model-id register 0x0016 = **0x0471** on the wire. This corrects the public assumption that the OLED SKU uses an OmniVision OV08X40 (we initially chased that: binding ov08x40 to TBE20A0 probes but fails, and its 5 ms post-reset delay is also too short for this module — it needs ~50 ms before it ACKs on I2C). Kate's v6 series works on this SKU too: built out-of-tree against Arch Linux 7.1.3, camera runs end-to-end (libcamera 0.7.1 software ISP, 1928x1088 → 30 fps in Teams/browsers). One note for anyone backporting: without patch 3/4 (the int3472 "vana" con_id remap), the driver's "vana" supply maps to a dummy regulator and probing fails with -121; renaming the supply to "avdd" in the driver is the stopgap. Full write-up incl. desktop plumbing (pipewire-libcamera / v4l2-relayd) and a hand-calibrated soft-ISP tuning file: https://github.com/ocewers/x1c14-camera-imx471 — framed explicitly as a workaround until the series reaches distro kernels. Image quality wise the remaining gap is the software ISP's maturity (3A, per-sensor tuning) rather than anything sensor-specific — happy to test on this SKU if the softISP calibration/tuning work ever needs an IMX471 data point. Kate — thank you for the driver and the enablement work. It turned a camera that was widely believed unsupportable (or mis-identified) on this SKU into a working one; much appreciated.
(In reply to ola.cewers from comment #43) > Confirmation from another SKU: the 2.8K OLED variant of the X1 Carbon Gen 14 > (type 21V7CTO1WW, camera option "10MP RGB+IR with ToF") also has the > **IMX471** > behind ACPI `TBE20A0` — chip-verified, not inferred: with the sensor powered > we > read CCS model-id register 0x0016 = **0x0471** on the wire. This corrects the > public assumption that the OLED SKU uses an OmniVision OV08X40 (we initially > chased that: binding ov08x40 to TBE20A0 probes but fails, and its 5 ms > post-reset delay is also too short for this module — it needs ~50 ms before > it > ACKs on I2C). Right, both TBE20A0 (for earlier model) and SONY471A (newer model) indicate imx471 sensor. It also can be found in the intel's imx471 driver placed in intel ipu6-drivers git repo. > > Kate's v6 series works on this SKU too: built out-of-tree against Arch Linux > 7.1.3, camera runs end-to-end (libcamera 0.7.1 software ISP, 1928x1088 → 30 > fps > in Teams/browsers). One note for anyone backporting: without patch 3/4 (the > int3472 "vana" con_id remap), the driver's "vana" supply maps to a dummy > regulator and probing fails with -121; renaming the supply to "avdd" in the > driver is the stopgap. It should be avdd but consider the dt compatibility, the regulator was renamed to vana in INT3472 driver to match the datasheet. So the patch (the int3472 "vana" con_id remap) is necessary. > > Full write-up incl. desktop plumbing (pipewire-libcamera / v4l2-relayd) and a > hand-calibrated soft-ISP tuning file: > https://github.com/ocewers/x1c14-camera-imx471 > — framed explicitly as a workaround until the series reaches distro kernels. > Image quality wise the remaining gap is the software ISP's maturity (3A, > per-sensor tuning) rather than anything sensor-specific — happy to test on > this SKU if the softISP calibration/tuning work ever needs an IMX471 data > point. Thank you for your tuning file. I'll test it too :) > > Kate — thank you for the driver and the enablement work. It turned a camera > that was widely believed unsupportable (or mis-identified) on this SKU into a > working one; much appreciated. Thank you for your work. :)
Follow-up for this hardware family: the IR camera on the X1 Carbon Gen 14 (ACPI TBE20A1, sibling of the TBE20A0 IMX471 this bug covered) is an ST VD55G1 — identified via the tuning metadata in Lenovo's Windows driver package and confirmed on the wire by the mainline vd55g1 driver's model-id readback (0x53354731, mono). It streams on Linux (Y10 804x704@30, working AE, concurrent with the IMX471) with four small patches: an ACPI match table for vd55g1 (the driver is DT-only today), an ipu-bridge entry, the int3472 "vana" power-enable mapping in the same pattern as your IMX471 patch 3/4, and a missing V4L2_PIX_FMT_Y10 row in the ipu7-isys pixel format table (the CSI2/MIPI side already handles Y10, so mono sensors currently die at STREAMON with EPIPE). Patches, identification evidence, probe logs, and capture recipe: https://github.com/jriff/x1c14-ir-vd55g1 Feel free to take these forward in whatever form suits your upstream work. One open item we couldn't solve from the OS side: the IR emitter isn't driven yet, so indoor LED-lit scenes are near-black (works fine in daylight).
@jacob Can you please file a new bz against to it? One bz ticket for one issue, otherwise it is difficult to track the issue. I found it already based on fwnode to get the device description and configuration so adding the HID to the acpi_match_table is sufficient for the driver changes. But the major problem is that I don't have a X1 G14 :( Thank you :)
(In reply to Kate Hsuan from comment #46) > @jacob > > Can you please file a new bz against to it? One bz ticket for one issue, > otherwise it is difficult to track the issue. > > I found it already based on fwnode to get the device description and > configuration so adding the HID to the acpi_match_table is sufficient for > the driver changes. > But the major problem is that I don't have a X1 G14 :( > > Thank you :) Filed as bug 2509956. Would love to help :^)