Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
[Regression] linux-ptl 7.2.3: IPU7 / OV08X40 sensor missing from media graph on Dell XPS 14 DA14260
Reported by milep · filed Sep 9, 2026Closed upstream on 2026-09-13 by the merge of PR omacom/omarchy-pkgs#418 (closed by spencerbull). GitHub close reason: completed.
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- Not yet mapped to any requirement or component.
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
System details
Dell XPS 14 DA14260 Intel Panther Lake, Core Ultra X7 358H Intel Arc B390 using xe IPU7 camera controller: 8086:b05d Sensor: OmniVision OV08X40 Sensor ACPI ID: OVTI08F4 Intel CVS ACPI device: INTC10E1 Camera userspace path: icamerasrc / Intel HAL -> v4l2-relayd -> v4l2loopback /dev/video50 -> Chromium / WebRTC
What's wrong?
Known-good snapshot
Omarchy 4.0.2-1
Kernel 7.1.8-arch1-2-ptl
intel-ipu7-camera 1.0.5-1
jsoncpp 1.9.6-3
Chromium 151.0.7922.173-1
WirePlumber 0.5.15-1
The camera works after restoring this snapshot.
The media graph contains the OV08X40 sensor, its enabled link, and /dev/v4l-subdev0 through /dev/v4l-subdev4.
Failing system
Omarchy 4.0.3-1
Kernel 7.2.3-arch1-1-ptl
intel-ipu7-camera 1.0.5-1
jsoncpp 1.9.8-1
Chromium 152.0.7977.82-1
WirePlumber 0.5.17-1
Problem
After the update, the built-in IPU7 camera no longer produces video.
There were two separate faults.
- JSONcpp ABI mismatch
/usr/lib/libcamhal/plugins/ipu75xa.so from intel-ipu7-camera 1.0.5-1 requires:
libjsoncpp.so.26
The updated jsoncpp 1.9.8-1 package provides ABI 27 instead.
This problem is already reported in omacom/omarchy#10837, with a packaging fix proposed in omacom/omarchy-pkgs#357.
For diagnosis, I installed the real ABI 26 library as a separate compatibility package. This allowed the HAL plugin to load again.
However, camera capture still did not work.
Therefore, the remaining failure is separate from the JSONcpp ABI problem.
Remaining kernel / media graph failure
On kernel 7.2.3-arch1-1-ptl, the OV08X40 sensor driver binds to I2C, but the sensor does not appear in the media graph.
There are also no /dev/v4l-subdev* nodes.
gst-inspect as root reports:
No sensors available
The V4L2 async debug state contains:
ov08x40 16-0036:
ipu7:
[fwnode] dev=nil, node=INTC10E1-0/port@1/endpoint@0
devices_deferred is empty.
On the working 7.1.8-arch1-2-ptl snapshot, the media graph contains the OV08X40 sensor and its enabled link, and the V4L2 subdevice nodes exist.
Possible Linux 7.2 CVS configuration regression
Linux 7.2 has an in-tree Intel CVS CSI-2 bridge driver:
CONFIG_VIDEO_INTEL_CVS
The upstream Kconfig describes this driver as a V4L2 subdevice that arbitrates CSI-2 ownership between the host and CVS firmware and configures the device for camera sensor streaming.
The module name is:
intel_cvs
The current Omarchy linux-ptl package is 7.2.3.arch1-1.
Its PKGBUILD copies config.x86_64 and then runs:
make olddefconfig
I cannot find CONFIG_VIDEO_INTEL_CVS in the current Omarchy linux-ptl/config.x86_64.
The upstream option defaults to N when it is not selected.
This appears relevant because the unresolved V4L2 async endpoint on the failing system is specifically:
INTC10E1-0/port@1/endpoint@0
This is the Intel CVS device in this camera topology.
I have not yet proved that enabling CONFIG_VIDEO_INTEL_CVS=m alone fixes the camera, so I am reporting this as the main hypothesis rather than as a confirmed root cause.
There may also be an interaction with the older CVS DKMS implementation included by intel-ipu7-camera, so I do not want to test this by forcing module removal or reloading camera/GPU modules on the live graphical system.
Reproduction
Boot the known-good Omarchy 4.0.2-1 snapshot with kernel 7.1.8-arch1-2-ptl.
Confirm that OV08X40 is present in the media graph and that /dev/v4l-subdev* nodes exist.
Confirm that camera capture and Google Meet work.
Update to Omarchy 4.0.3-1 and kernel 7.2.3-arch1-1-ptl.
Resolve the separate JSONcpp ABI mismatch so that the Intel HAL can load.
Reboot.
Inspect the media graph.
OV08X40 is missing, /dev/v4l-subdev* nodes are absent, and the IPU7 async notifier is still waiting for the INTC10E1 endpoint.
Capture verification
A one-frame V4L2 capture can give a misleading result.
A longer 60-frame capture times out.
A WebRTC test can also show a black preview with Success! and FPS NaN. This is not working video.
Browser and site permission resets do not change the failure.
The v4l2-relayd override and camera label configuration are unchanged package defaults.
Disabling an additional local resume hook also does not fix the failure after a cold boot.
Restoring the old snapshot restores camera operation.
Because the snapshot rollback changes several packages at once, this A/B test does not by itself prove that the kernel is the only changed component.
Expected result
On the supported Panther Lake kernel:
OVTI08F4 / OV08X40 should register in the media graph.
The required CVS / IPU7 V4L2 subdevices should register.
/dev/v4l-subdev* nodes should exist.
The IPU7 async notifier should not remain pending on the INTC10E1 endpoint.
A sustained multi-frame camera capture should complete without timeout.
Questions
Could you confirm whether linux-ptl 7.2.3 should enable:
CONFIG_VIDEO_INTEL_CVS=m
and whether Linux 7.2 is expected to use the new in-tree CVS V4L2 bridge instead of, or in coordination with, the older CVS DKMS component shipped by intel-ipu7-camera?
If the in-tree CVS driver supersedes the older Panther Lake CVS workaround, the package combination may need to be updated as one coordinated change.
I am happy to test a kernel/package build through cold boots with snapshot rollback. I would prefer not to use forced module removal or live xe / IPU / CVS module reloads because this system has also shown display corruption and repeated:
xe: Timed out waiting for PSR Idle for re-enable
I do not know whether that display problem is related to the camera regression.
View raw text
### System details Dell XPS 14 DA14260 Intel Panther Lake, Core Ultra X7 358H Intel Arc B390 using xe IPU7 camera controller: 8086:b05d Sensor: OmniVision OV08X40 Sensor ACPI ID: OVTI08F4 Intel CVS ACPI device: INTC10E1 Camera userspace path: icamerasrc / Intel HAL -> v4l2-relayd -> v4l2loopback /dev/video50 -> Chromium / WebRTC ### What's wrong? Known-good snapshot Omarchy 4.0.2-1 Kernel 7.1.8-arch1-2-ptl intel-ipu7-camera 1.0.5-1 jsoncpp 1.9.6-3 Chromium 151.0.7922.173-1 WirePlumber 0.5.15-1 The camera works after restoring this snapshot. The media graph contains the OV08X40 sensor, its enabled link, and /dev/v4l-subdev0 through /dev/v4l-subdev4. Failing system Omarchy 4.0.3-1 Kernel 7.2.3-arch1-1-ptl intel-ipu7-camera 1.0.5-1 jsoncpp 1.9.8-1 Chromium 152.0.7977.82-1 WirePlumber 0.5.17-1 Problem After the update, the built-in IPU7 camera no longer produces video. There were two separate faults. 1. JSONcpp ABI mismatch /usr/lib/libcamhal/plugins/ipu75xa.so from intel-ipu7-camera 1.0.5-1 requires: libjsoncpp.so.26 The updated jsoncpp 1.9.8-1 package provides ABI 27 instead. This problem is already reported in omacom/omarchy#10837, with a packaging fix proposed in omacom/omarchy-pkgs#357. For diagnosis, I installed the real ABI 26 library as a separate compatibility package. This allowed the HAL plugin to load again. However, camera capture still did not work. Therefore, the remaining failure is separate from the JSONcpp ABI problem. Remaining kernel / media graph failure On kernel 7.2.3-arch1-1-ptl, the OV08X40 sensor driver binds to I2C, but the sensor does not appear in the media graph. There are also no /dev/v4l-subdev* nodes. gst-inspect as root reports: No sensors available The V4L2 async debug state contains: ov08x40 16-0036: ipu7: [fwnode] dev=nil, node=INTC10E1-0/port@1/endpoint@0 devices_deferred is empty. On the working 7.1.8-arch1-2-ptl snapshot, the media graph contains the OV08X40 sensor and its enabled link, and the V4L2 subdevice nodes exist. Possible Linux 7.2 CVS configuration regression Linux 7.2 has an in-tree Intel CVS CSI-2 bridge driver: CONFIG_VIDEO_INTEL_CVS The upstream Kconfig describes this driver as a V4L2 subdevice that arbitrates CSI-2 ownership between the host and CVS firmware and configures the device for camera sensor streaming. The module name is: intel_cvs The current Omarchy linux-ptl package is 7.2.3.arch1-1. Its PKGBUILD copies config.x86_64 and then runs: make olddefconfig I cannot find CONFIG_VIDEO_INTEL_CVS in the current Omarchy linux-ptl/config.x86_64. The upstream option defaults to N when it is not selected. This appears relevant because the unresolved V4L2 async endpoint on the failing system is specifically: INTC10E1-0/port@1/endpoint@0 This is the Intel CVS device in this camera topology. I have not yet proved that enabling CONFIG_VIDEO_INTEL_CVS=m alone fixes the camera, so I am reporting this as the main hypothesis rather than as a confirmed root cause. There may also be an interaction with the older CVS DKMS implementation included by intel-ipu7-camera, so I do not want to test this by forcing module removal or reloading camera/GPU modules on the live graphical system. Reproduction Boot the known-good Omarchy 4.0.2-1 snapshot with kernel 7.1.8-arch1-2-ptl. Confirm that OV08X40 is present in the media graph and that /dev/v4l-subdev* nodes exist. Confirm that camera capture and Google Meet work. Update to Omarchy 4.0.3-1 and kernel 7.2.3-arch1-1-ptl. Resolve the separate JSONcpp ABI mismatch so that the Intel HAL can load. Reboot. Inspect the media graph. OV08X40 is missing, /dev/v4l-subdev* nodes are absent, and the IPU7 async notifier is still waiting for the INTC10E1 endpoint. Capture verification A one-frame V4L2 capture can give a misleading result. A longer 60-frame capture times out. A WebRTC test can also show a black preview with Success! and FPS NaN. This is not working video. Browser and site permission resets do not change the failure. The v4l2-relayd override and camera label configuration are unchanged package defaults. Disabling an additional local resume hook also does not fix the failure after a cold boot. Restoring the old snapshot restores camera operation. Because the snapshot rollback changes several packages at once, this A/B test does not by itself prove that the kernel is the only changed component. Expected result On the supported Panther Lake kernel: OVTI08F4 / OV08X40 should register in the media graph. The required CVS / IPU7 V4L2 subdevices should register. /dev/v4l-subdev* nodes should exist. The IPU7 async notifier should not remain pending on the INTC10E1 endpoint. A sustained multi-frame camera capture should complete without timeout. Questions Could you confirm whether linux-ptl 7.2.3 should enable: CONFIG_VIDEO_INTEL_CVS=m and whether Linux 7.2 is expected to use the new in-tree CVS V4L2 bridge instead of, or in coordination with, the older CVS DKMS component shipped by intel-ipu7-camera? If the in-tree CVS driver supersedes the older Panther Lake CVS workaround, the package combination may need to be updated as one coordinated change. I am happy to test a kernel/package build through cold boots with snapshot rollback. I would prefer not to use forced module removal or live xe / IPU / CVS module reloads because this system has also shown display corruption and repeated: xe: Timed out waiting for PSR Idle for re-enable I do not know whether that display problem is related to the camera regression.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
No decision has been recorded yet.