Make the Intel IPU6 camera work out of the box - #11033
Open
ianswope wants to merge 1 commit into
Open
Conversation
IPU6 laptops (XPS 14/16 and most Meteor/Arrow Lake machines) currently get no usable camera on Omarchy. The kernel drives the sensor, but only as dozens of raw Bayer /dev/video* nodes, so browsers enumerate them and show a black or green frame. libcamera's software ISP is the only path that produces a picture, and neither libcamera nor pipewire-libcamera is installed today. So: install both when IPU6 is present, and turn off the v4l2 monitor so libcamera owns the camera. USB webcams still work -- libcamera picks up UVC devices through its own pipeline. Gated on /sys/bus/pci/drivers/intel-ipu6, which is version-specific and so does not fire on the IPU7 hardware already handled next door. Note for reviewers: the drop-in disables the whole v4l2 monitor rather than setting device.disabled on the IPU6 device, which is what wireplumber's own docs suggest. That is deliberate. monitors/v4l2/create-device.lua returns without calling transition:advance() for a disabled device, so the async hook never completes and the event dispatcher stalls permanently: the libcamera camera node is never created, and if the sound card finishes probing after that event its profile is never selected either, leaving the machine with no camera and no built-in mic or speakers. Silent -- one log notice and then nothing. Present in wireplumber 0.5.17 and master, so the rules form would ship that failure to every IPU6 user. Reported upstream: https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/1010
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The problem
On IPU6 laptops — XPS 14/16 and most Meteor/Arrow Lake machines — Omarchy has no
usable camera out of the box. The kernel drives the sensor, but only as dozens of
raw Bayer
/dev/video*nodes. Browsers enumerate those and show a black or greenframe. libcamera's software ISP is the only path that produces a picture, and
neither
libcameranorpipewire-libcamerais installed today.IPU7 already gets hardware enablement in
install/hardware/intel/ipu7-camera.sh.This does the equivalent for IPU6, plus the WirePlumber side.
What this does
bin/omarchy-hw-intel-ipu6— gates on/sys/bus/pci/drivers/intel-ipu6. Thedriver name is version-specific, so it will not fire on the IPU7 hardware
handled next door.
install/hardware/intel/ipu6-camera.sh— installslibcameraandpipewire-libcamerawhen that gate passes.default/wireplumber/wireplumber.conf.d/ipu6-prefer-libcamera.conf— turns offthe v4l2 monitor so libcamera owns the camera.
install/user/hardware/intel/ipu6-prefer-libcamera.sh— copies the drop-in,mirroring the existing
asus/fix-audio-mixer.shpattern.install/hardware/all.shandinstall/user/all.sh.USB webcams still work: libcamera picks up UVC devices through its own pipeline.
Why the profile switch and not
device.disabledWirePlumber's docs suggest tagging the IPU6 device with
device.disabledinmonitor.v4l2.rules. Please don't take that route here — it ships a silentfailure.
monitors/v4l2/create-device.luareturns from itsAsyncEventHookstep withoutcalling
transition:advance()for a disabled device. The hook never completes,so the event dispatcher stalls permanently and every event queued behind it is
dropped: the libcamera camera node is never created, and if the sound card
finishes probing after that event its profile is never selected either — leaving
the machine with no camera and no built-in mic or speakers. There is no error;
one log notice, then the daemon goes quiet.
Reported upstream, with the one-line fix:
https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/1010
Disabling the monitor at the profile level never enters that branch, so this is
correct both before and after upstream fixes it.
Testing
Dell XPS 14 (DA14250, Arrow Lake, ov02c10 behind IPU6), kernel 7.2.3,
wireplumber 0.5.17, pipewire 1.6.8, libcamera 0.7.2. The gate returns true; with
the drop-in in place
wpctl statusshows a singleov02c10 [libcamera]deviceand a "Built-in Front Camera" source, the raw
ipu6nodes stay out of the graph,and the camera works in Chrome. The drop-in is byte-identical, comments aside, to
the config that has been running on that machine.
Not tested on IPU7 hardware, and not tested with a USB webcam attached — UVC
should still arrive via libcamera, but I have not verified it.