Webcam not detected on Omarchy

Most “no webcam” reports on Omarchy are not one bug. They are five or six different machines whose only shared symptom is an empty camera list. Work out which one you have before you change anything.

The fix

1. Identify what you actually have.

v4l2-ctl --list-devices
lsusb | grep -i cam
lspci -nn | grep -iE 'ipu|multimedia|camera'
for d in /sys/bus/acpi/devices/*/; do
  printf '%s %s\n' "$(cat "$d/hid" 2>/dev/null)" "$(cat "$d/status" 2>/dev/null)"
done | grep -iE 'OVTI|TBE|SONY|INT3472|INTC10'

If lsusb names your camera, it is an ordinary UVC device and none of the Intel sections below apply. If lspci shows an Intel IPU (it is listed as a multimedia controller), the PCI ID decides the rest: 8086:b05d is Panther Lake IPU7.5, 8086:645d is Lunar Lake, 8086:7d19 is Meteor Lake IPU6.

2. Panther Lake (8086:b05d, sensor OVTI08F4 with status 15). This is the Dell XPS 14 and XPS 16 case, and it is the one Omarchy fixed. Update and reboot:

omarchy update   # or Update > Omarchy in the menu, then reboot

4.0.4 carries intel-ipu7-camera 1.0.6, which adds a DKMS build of the in-tree Intel CVS bridge driver for 7.2 kernels, patches the HAL to route the sensor link through that entity, and gates the old vision-drivers module to pre-7.2 kernels. A reboot is required, not just a service restart. The release notes list it as a webcam fix for XPS systems on 7.2.x.

3. Still on 4.0.3, camera died after a normal update. Check the HAL plugin:

ldd /usr/lib/libcamhal/plugins/ipu75xa.so | grep -i json

libjsoncpp.so.26 => not found means you hit the jsoncpp 1.9.8 soname bump. Updating to 4.0.4 resolves it. The v4l2-relayd journal shows nothing but GLib assertions and never names jsoncpp, so run the ldd check before you blame the kernel.

4. Lunar Lake (8086:645d, Core Ultra 200V). The package is installed by detection but built with IPU_VERSIONS="ipu75xa" only, so the plugin your IPU asks for, ipu7x.so, is not on disk. There is no packaged fix as of 4.0.4. If you want the fake camera out of the way:

omarchy-pkg-drop intel-ipu7-camera

5. IPU6 laptops (Meteor Lake and older, sensors OVTI01A0, OVTI02C1, OVTI2740). Omarchy ships no IPU6 leaf at all. Worse, if your firmware also exposes an OVTI08F4 node, the IPU7 package installs and hides the raw nodes behind a black /dev/video50. Drop it first, then try the libcamera route:

omarchy-pkg-drop intel-ipu7-camera
sudo pacman -S libcamera libcamera-ipa libcamera-tools pipewire-libcamera
cam -l

That is the route reporters use for PipeWire-native apps, and it only helps once cam -l lists the sensor. One Raptor Lake owner needed kernel patches that are still an open omarchy-pkgs PR before his OV02C10 would probe at all. Most browsers still want a real /dev/video node, which means a libcamerasrc to v4l2sink bridge on a v4l2loopback device, or Chromium’s WebRtcPipeWireCamera feature flag.

6. ThinkPad X1 Carbon Gen 14 and X9 15p. If OVTI08F4 reports status 0 and TBE20A0 reports 15, your sensor is a Sony IMX471 and the OV08X40 stack can never drive it. The driver and its ACPI binding both landed upstream after 7.2 was tagged, so Arch gets them at 7.3. Until then people are running imx471-dkms-git plus the libcamera plumbing in ocewers/x1c14-camera-imx471. Keep intel-ipu7-camera installed on that route: the overlays swap its icamerasrc relay for libcamerasrc and reuse its loopback plumbing instead of replacing the package.

7. Macs. On T2 machines the camera comes from linux-t2 and uvcvideo. On pre-T2 models the FaceTime HD 1570 has no in-tree driver and Omarchy ships nothing for it. See /hardware/t2-mac/.

Verify it worked

omarchy-capture-webcam-list
media-ctl -p -d /dev/media0 | grep -i ov08x40     # Intel IPU only
gst-launch-1.0 icamerasrc num-buffers=5 ! fakesink

On a working Intel IPU machine the media graph shows the sensor entity, and on 7.2 it links through an Intel CVS entity rather than straight to CSI2. Then open a camera in a browser. The first loopback frame is black while the ISP warms up, so give it a second before you call it dead.

Why it happens

Omarchy’s entire built-in camera setup is three lines in install/hardware/intel/ipu7-camera.sh. It greps /sys/bus/acpi/devices/*/hid for OVTI08F4 and installs intel-ipu7-camera if it finds it. It does not check whether the node is enabled, which IPU controller is present, or which sensor is live. That single gate produces most of the cases above: it fires on ThinkPads whose OVTI08F4 is a disabled table slot, on Meteor Lake machines the package cannot serve, and on Lunar Lake machines whose HAL plugin was never built.

The package then does real work on the system. It blacklists ov08x40 behind intel_cvs, hides the raw V4L2 nodes with a udev rule, turns off WirePlumber’s libcamera monitor, and publishes /dev/video50 from icamerasrc. So when it lands on hardware it cannot drive, you get a camera that appears everywhere and delivers nothing, which is worse than having no node at all.

The Panther Lake break on kernel 7.2 was separate and specific. Linux 7.2’s ipu-bridge started placing the Intel CVS controller between the sensor and the CSI2 receiver, and added a matching in-tree V4L2 bridge driver. The package’s own out-of-tree intel_cvs has the same module name and installs into updates/, which depmod searches first, so on linux-omarchy it displaced the in-tree driver. linux-ptl could not build the in-tree one at all, because Arch-derived configs hide the option. Either way the old module registers no subdev, the IPU waited forever for one, and the sensor never joined the media graph. Several reporters on the XPS thread reached the same mechanism before the fix landed.

If that did not work

No /dev/video* at all and lsusb shows nothing. Check the BIOS for a camera or I/O port access toggle, and any physical shutter. Some laptops simply have no Linux driver. On a report about an Acer Nitro whose camera also failed on Ubuntu, DHH answered that it has to be fixed upstream or by the vendor.

Camera works in qcam but never in the browser. A Surface Pro report traced that to the portal, not the driver: the GTK portal rejects Hyprland’s toplevel handle and the camera request fails quietly. Watch journalctl --user -f -u xdg-desktop-portal-gtk while you trigger it.

Camera works at boot and dies after the first suspend. On Panther Lake the ov08x40 bind is dropped on resume and camera-init cannot restore it, so only a reboot brings it back. The 7.2 stack in 4.0.4 uses the in-tree CVS driver with real PM ops, and the PR author ran two s2idle cycles on an XPS 14 with it and kept the sensor both times, so update before you chase this further.

Screen recording shows a black webcam overlay. The picker only filters on Device Caps, and IPU7 raw Bayer nodes advertise Video Capture while offering no format mpv can read. Pick the v4l2loopback entry (/dev/video50 on the Omarchy package) by hand instead of letting auto-detect take the first one.

Related

• /hardware/webcam/ for the per machine status table
• /hardware/dell-xps-14-2026/ and /hardware/lenovo-thinkpad-x1-carbon/
• /hardware/t2-mac/ for Apple hardware, including what a full disk install costs you
• /fix/suspend-wont-resume-s2idle/ if the camera is one of several things lost on resume
• /switch/screen-sharing-meet-zoom-teams/ for the portal side of calls
• /reference/commands/omarchy-hw-webcam/ for what the detection check actually runs
• The Omarchy manual covers the overlay in Screenshots and Recording