Summary

The integrated OV02C10 MIPI camera on this system negotiates and streams successfully through the entire Linux camera stack (IPU6, CamHAL, GStreamer, PipeWire, v4l2loopack, Cheese) with no errors at any layer, but every captured frame is a flat, uniform value (NV12 Y=16, i.e. solid black) rather than real image data. The same physical camera works correctly under Windows on this same machine, confirming the hardware itself is functional.

A similar symptom (identical sensor, clean pipeline negotiation, flat black output) was previously root-caused on a different Dell model, the Dell 16 Premium DA16250, also OV02C10 on Meteor Lake — see "Related report" below — where kernel maintainers traced it to the RGB sensor's PMIC/power-rail topology being left disabled in that model's firmware. It's worth noting the XPS 16 9640's ArchWiki page states this same IPU6+OV02C10 camera is "supported upstream as of Linux 6.16" on this model, based on other owners' reports — so this may or may not be the same root cause here; flagging the DA16250 report as a plausible parallel worth checking against, not a confirmed match.

System information

• Hardware: Dell XPS 16 9640 (Meteor Lake platform)
• Camera sensor: OmniVision OV02C10 (media entity: ov02c10 20-0036, device node /dev/v4l-subdev7)
• IPU: Intel IPU6 (PCI 0000:00:05.0)
• OS: Ubuntu 24.04 LTS
• Kernel: OEM kernel, linux-modules-ipu6-oem-24.04d (currently 6.17.0-1030.30, also reproduced on 6.17.0-1030 prior to this)
• Camera userspace stack: Dell Somerville PPA (dell.archive.canonical.com), packages at latest available snapshot:
  • gstreamer1.0-icamera 0~git202509260937.4fb31db~ubuntu24.04.5
  • libcamhal0 0~git202506270118.c933525~ubuntu24.04.5
  • v4l2-relayd 0.1.2-0ubuntu3.1
• Dual boot: Yes — camera works correctly under Windows on the same hardware.

Steps to reproduce

1. Boot into Ubuntu 24.04 (OEM kernel).
2. Open Cheese, or run:

   gst-launch-1.0 v4l2src device=/dev/video0 ! videoconvert ! fakesink -v

3. Pipeline negotiates NV12 1280x720@30fps successfully, PLAYING state reached, no GStreamer/CamHAL errors.
4. Captured frame data is uniformly flat (see raw frame analysis below) — visually, this appears as a solid black picture in any viewer.

Diagnostic steps already taken (ruling out other causes)

• BIOS: Security → I/O Port Access → Camera confirmed Enabled in BIOS setup.
• Firmware attribute (sysfs): /sys/devices/virtual/firmware-attributes/dell-wmi-sysman/attributes/Camera/current_value initially read Disabled despite BIOS showing Enabled; corrected via echo Enabled | sudo tee .../current_value and rebooted — no change in symptom.
• Physical shutter: No physical camera shutter/slider present on this model.
• Dell hardware privacy driver: dell_privacy_supported_type reports Microphone / Camera Shutter / ePrivacy Screen all as [unsupported] on this model — ruled out as the cause.
• IVSC privacy mode: Checked directly via the IVSC CSI subdevice's V4L2 privacy control — reads value=0 (not engaged). Privacy mode is not active.
• Sensor-level V4L2 controls (/dev/v4l-subdev7, ov02c10): all present and nominal (exposure=2320 (max), analogue_gain=16 (min), digital_gain=1024 (min), test_pattern=Disabled) — consistent with a sensor that never receives real incoming light/signal rather than a misconfigured one.
• Kernel module stack: intel_ipu6, intel_ipu6_isys, ivsc_csi, ivsc_ace, mei_vsc, mei_vsc_hw, ov02c10 all load correctly with no errors.
• dmesg at boot: CSE authentication completes successfully:

  intel-ipu6 0000:00:05.0: Sending BOOT_LOAD to CSEintel-ipu6 0000:00:05.0: Sending AUTHENTICATE_RUN to CSEintel-ipu6 0000:00:05.0: CSE authenticate_run done

• Raw frame analysis — captured a single frame directly from /dev/video0 and inspected the NV12 Y (luma) plane:

  min: 16   max: 16   average: 16.0

  Every single pixel is exactly 16 (standard "broadcast black" placeholder value) with zero variation — not merely dark or low-light, but a synthetic uniform frame, consistent with the sensor never actually being handed real signal.
• Kernel and driver updates: Updated linux-modules-ipu6-* packages to latest available in noble-updates/noble-security, and confirmed gstreamer1.0-icamera / libcamhal0 are already at the latest available snapshot from the Somerville PPA. No change in symptom after updating and rebooting.

Related report

This appears to match: "Dell 16 Premium (DA16250): RGB camera (OV02C10) unusable on Linux — RGB-side INT3472 PMIC topology left disabled in firmware NVS" (Dell Community, DELL Technologies forum). That investigation, conducted with IPU6/int3472 kernel maintainers (Hans de Goede, Sakari Ailus, Ilpo Järvinen, Marco Nenciarini), concluded that the OV02C10's required power rails (avdd/dovdd/dvdd via INT3472 PMIC instances) are left disabled in the platform's firmware NVS configuration for the Linux SKU, and that this cannot be fixed in-kernel — it requires the firmware to expose the RGB-side PMIC topology as it does for Windows.

Given the identical sensor, identical platform generation, and identical symptom (clean negotiation, flat/black output, works on Windows), it's possible this report describes the same underlying firmware issue on this model too — though note the XPS 16 9640's ArchWiki page reports this camera as "supported upstream as of Linux 6.16" based on other users' experience, and this system is already on a newer OEM kernel (6.17.x), so a kernel-version gap doesn't appear to explain the difference. Requesting investigation into whether this system's specific firmware has a PMIC topology limitation similar to the DA16250 case, or whether the cause here is something else given that other XPS 16 9640 units reportedly work.

Expected behavior

Camera should capture real image data on Linux, matching its behavior under Windows on the same hardware.

Actual behavior

Camera pipeline reports full success at every software layer but only ever produces flat, uniform black frames.