IPU6 webcam unusable on IVSC-equipped laptops (e.g. Dell Latitude 7340) — blocks video calls

Summary

Can't join video calls (Teams, etc.) from the built-in webcam on IVSC-equipped IPU6 laptops — common on Dell/Lenovo business models with a hardware privacy co-processor. Browsers show no camera at all, even with the fix in #12636 applied. Root-caused this below; filing separately from #12636 since it's a distinct blocker that affects a real subset of hardware that PR doesn't account for, and separately from #8843 since that's a different failure mode further down the stack.

Environment

• Dell Latitude 7340, 13th Gen Intel Core i7-1365U (Raptor Lake-U)
• Intel IPU6 MIPI camera controller (intel_ipu6/intel_ipu6_isys, mainlined, no out-of-tree driver needed), ov02c10 (OmniVision) sensor
• Omarchy, kernel 7.2.8-9-omarchy

Reproduction

1. Install the IPU6 camera stack from #12636 manually: omarchy pkg add libcamera pipewire-libcamera gst-plugin-libcamera, then systemctl --user restart pipewire pipewire-pulse wireplumber.
2. Open Teams (or any browser camera permission prompt) — camera dropdown stays grayed out / "no camera available".

Evidence

journalctl --user -u wireplumber:

ERROR V4L2 v4l2_device.cpp:92 'ov02c10 14-0036': Failed to open V4L2 device '': No such file or directory
ERROR CameraSensor camera_sensor.cpp:470 Failed to create sensor for 'ov02c10 14-0036: -2
ERROR SimplePipeline simple.cpp:1930 No valid pipeline for sensor 'ov02c10 14-0036', skipping

media-ctl -d /dev/media0 -p — every entity has a device node name line except the sensor itself:

entity 233: Intel IVSC CSI      device node name /dev/v4l-subdev4
entity 248: ov02c10 14-0036     (no device node line — none exists)

Why it fails

This laptop's camera sits behind Intel's IVSC (Visual Sensing Controller) — a privacy/security co-processor in the hardware path between the sensor and the ISP (ivsc_csi/ivsc_ace/mei_vsc kernel modules, all loaded and functioning). By IVSC's design, the sensor's I2C control plane is kept exclusive to IVSC firmware, so only the IVSC CSI bridge entity gets a device node — the sensor entity never does.

libcamera's SimplePipeline handler assumes every sensor entity has its own openable device node (true for plain UVC-style setups and apparently true on #12636's test machine, a Latitude 9440, whose media graph presumably doesn't route through IVSC). On IVSC-equipped hardware that assumption breaks: it resolves an empty device path for the sensor and fails with ENOENT.

Ruled out before landing on this:

• Not a permissions issue. getfacl on every relevant /dev/v4l-subdev*//dev/media0 node shows an explicit user:<me>:rw- ACL via systemd-logind's uaccess seat tagging.
• Not Dell's hardware privacy shutter. dell_privacy_supported_type (WMI) reports Microphone, Camera Shutter, and ePrivacy Screen all [unsupported] on this model.
• Not a manually-triggerable ownership handoff. The sensor's V4L2_CID_PRIVACY control is read-only and already shows value=0 (not blocked). Per the upstream kernel driver series ("media: pci: intel: ivsc: Add acquire/release API for ivsc"), the IVSC acquire/release handoff is an in-kernel API (include/linux/ivsc.h), not a userspace-writable control — there's no command to run to fix this at runtime.

Possible fixes

• libcamera's pipeline handler needs IVSC-awareness: detect the IVSC CSI entity in the media graph and treat it as the sensor's effective control point when the sensor itself has no device node, rather than failing outright.
• Until that lands upstream, Omarchy's omarchy-hw-intel-ipu6 detector (from #12636) could at least warn/skip cleanly on IVSC-equipped hardware rather than silently installing a stack that can't produce a working camera, so affected users aren't left thinking something else is broken.

Related

• #12636 — the attempted IPU6 fix this builds on; works on non-IVSC hardware, doesn't account for IVSC.
• #8843 — a different, downstream failure mode (camera works at the libcamera/PipeWire level, but the Hyprland portal fails to hand it to the browser). Not applicable here since libcamera never gets a working camera node in the first place.