### System details

lenova x1 aura 14

### What's wrong?

## Summary

Built-in camera does not work on a fresh Omarchy install. `/dev/video*` nodes exist and the IPU7 kernel driver stack loads, but the camera sensor's ACPI device is disabled (`_STA` = 0) and never binds to an I2C instance. `dmesg` shows `IPU7 in secure mode`, which is a different (and less-documented) failure signature than the two outcomes usually reported for this hardware family (full CSE authentication failure, or successful authentication with "no subdev found in graph").

## System

- **Laptop:** Lenovo laptop, PCI subsystem ID `17aa:2352` — *"ThinkPad X1 Carbon Gen 14"*
- **CPU:** Intel Core Ultra 7 355 ("Panther Lake" class — IPU7)
- **OS:** Omarchy, `VERSION_ID="4.0.0"`
- **Kernel:** `7.1.8-arch1-3`
- **IPU:** `00:05.0 Multimedia controller [8086:b05d]` — "Core Ultra Processors (Series 3) IPU", driver in use `intel-ipu7`
- **Sensor:** OmniVision OV08X40 (ACPI HID `OVTI08F4`), companion node `OVTI01AF` (x3, likely IR/aux)

This is a fresh install — camera has not worked since the OS was installed on this hardware.

## Symptom

No application (tested via `v4l2-ctl`, and standard camera apps) can get a picture from the built-in camera. The only usable-looking `/dev/videoN` node (`/dev/video50`) is a `v4l2loopback` placeholder, not the real sensor — it never receives frames because nothing upstream is feeding it.

## Diagnostic evidence

**PCI / driver binding** — IPU7 PCI function binds fine:
```
00:05.0 Multimedia controller [0480]: Intel Corporation Core Ultra Processors (Series 3) IPU [8086:b05d] (rev 08)
	Subsystem: Lenovo Device [17aa:2352]
	Kernel driver in use: intel-ipu7
	Kernel modules: intel_ipu7
```

**Modules loaded** (all present, including `intel_cvs` which some other reports of this hardware family are missing entirely):
```
ov08x40, intel_ipu7_psys, intel_ipu7_isys, v4l2_fwnode, videobuf2_*,
v4l2_async, intel_ipu7, ipu_acpi, ipu_bridge, videodev, mc, v4l2loopback
intel_cvs (57344, in use count 0) — loaded from
  /lib/modules/7.1.8-arch1-3/updates/dkms/intel_cvs.ko.zst
```

**ACPI status of camera-related nodes** — the sensor itself is disabled at the firmware level:
```
/sys/bus/acpi/devices/OVTI01AF:00/status: 0
/sys/bus/acpi/devices/OVTI01AF:01/status: 0
/sys/bus/acpi/devices/OVTI01AF:02/status: 0
/sys/bus/acpi/devices/OVTI08F4:00/status: 0        <- the OV08X40 sensor node
/sys/bus/acpi/devices/INT3472:00/status: 15        <- companion chip, enabled
/sys/bus/acpi/devices/INT3472:01/status: 15        <- companion chip, enabled
/sys/bus/acpi/devices/INT3472:02..0b/status: 0
```

**I2C binding** — `ov08x40` driver has no bound device instance (directory only contains the standard `bind`/`unbind`/`module`/`uevent` attribute files, no device symlink):
```
$ ls /sys/bus/i2c/drivers/ov08x40/
bind  module  uevent  unbind
```

**dmesg (camera-relevant lines only):**
```
[55994.835277] intel-ipu7 0000:00:05.0: IPU7 in secure mode
```
No CSE authentication success/failure message appears at all — just this one "secure mode" line, and then nothing else camera-related. This differs from:
- `intel/ipu6-drivers#306`, where CSE authentication explicitly fails with `-EIO` / IPC response `0xd20`.
- `intel/ipu7-drivers#17`, where CSE authentication succeeds (`CSE authenticate_run done`) but the sensor subdev still isn't found in the media graph.

Here it looks like the driver detects it's running in a restricted "secure mode" and appears to stop short of even attempting sensor enumeration, which would explain why the ACPI `_STA` for `OVTI08F4` stays at 0 and no I2C device is ever instantiated for `ov08x40` to bind to.

**Secure Boot:** unknown — `mokutil` not installed on this system to check. Given `intel_cvs.ko.zst` is a DKMS-built, presumably unsigned module and it did load successfully, Secure Boot is either disabled or the module is enrolled via MOK.

## What's already ruled out

- Not the "missing `intel_cvs`" case from `basecamp/omarchy#6000` — `intel_cvs` is present and loaded here.
- Not a simple missing-kernel-module case — every relevant module (`intel_ipu7`, `intel_ipu7_isys`, `intel_ipu7_psys`, `ov08x40`, `ipu_bridge`, `ipu_acpi`, `intel_cvs`) is loaded.
- Not a BIOS toggle that's obviously off — the IPU7 PCI device itself is visible and bound.

## What we have not attempted

There's a community stopgap (out-of-tree/DKMS pipeline: build `intel_cvs` if missing, `libcamera` + `pipewire-libcamera`, a GStreamer relay into `v4l2loopback`, per [Theofilos-Chamalis/intel-ipu-webcam-linux-bridge-fix](https://github.com/Theofilos-Chamalis/intel-ipu-webcam-linux-bridge-fix) and the [CachyOS Panther Lake guide](https://github.com/CachyOS/linux-cachyos/issues/804)). We deliberately did not pursue it here because the underlying ACPI/CSE issue means it likely wouldn't produce a working feed anyway (the sensor never gets an I2C instance for `libcamera` to talk to either), and even where it works elsewhere it comes with real costs (unsigned kernel module, ~50-65% CPU during capture, rebuild-per-kernel-update, color/tint issues) — this report is about the root enumeration failure, not the userspace bridge.

## Related upstream reports

- [basecamp/omarchy#6000](https://github.com/basecamp/omarchy/issues/6000) — same IPU7-PTL / OV08X40 pairing on a different Lenovo ThinkPad X1 Carbon Gen 14 SKU, also ACPI status=0, but that report is missing `intel_cvs` entirely (different from this case)
- [intel/vision-drivers#36](https://github.com/intel/vision-drivers/issues/36) — `intel_cvs` criticality for IPU7/Panther Lake ACPI dependency chain
- [intel/ipu7-drivers#17](https://github.com/intel/ipu7-drivers/issues/17) — IPU7 loads, CSE auth succeeds, but "no subdev found in graph" (different failure point, same hardware family)
- [intel/ipu6-drivers#306](https://github.com/intel/ipu6-drivers/issues/306) — CSE `authenticate_run failed`, `-EIO` (predecessor generation, same failure category — firmware authentication)
- [CachyOS/linux-cachyos#804](https://github.com/CachyOS/linux-cachyos/issues/804) — practical Panther Lake/IPU7 camera setup guide (userspace bridge, not a root-cause fix)

## Ask

1. Is "IPU7 in secure mode" a known/expected transitional message, or does it indicate the CSE firmware authentication handshake is failing silently (no `-EIO`, no explicit error) before sensor enumeration even starts?
2. Does this Panther Lake IPU7 revision need a newer/different firmware blob (`/lib/firmware/intel/ipu/...`) than what currently ships, and if so where should that come from?
3. Is there a BIOS/firmware setting (equivalent to the "I/O Port Access → Integrated Camera" toggle mentioned in other Lenovo Panther Lake reports) that affects whether the IPU exits secure mode?

## How to reproduce this diagnostic output

```bash
lspci -nnk | grep -iA3 -E 'camera|imaging|ipu'
lsmod | grep -iE 'uvcvideo|ipu6|ipu7|ov[0-9]|cvs'
for f in /sys/bus/acpi/devices/OVTI*/status /sys/bus/acpi/devices/INT3472*/status; do echo "$f: $(cat "$f")"; done
ls /sys/bus/i2c/drivers/ov08x40/
sudo dmesg | grep -iE 'ipu7|ov08x40|isys|cvs|OVTI|INT3472|mipi'
```