How to use the IPU6 webcam with kernel 6.10+?

shtrom · 2026-01-12 05:50:55

reacocard wrote:

Steps that should replicate my setup:

Thanks for this! I finally have a working IPU6 cam on my 2024 XPS 16 (9640) https://wiki.archlinux.org/title/Dell_XPS_16_(9640) with 6.18.4-arch1-1 and the V4L2 loopback.

merijn · 2026-01-12 19:53:31

I've been able to get my webcam to work with libcamera, gstreamer, v4l2loopback, and chromium. I'll share the details here.
I'm not using the intel proprietary packages (intel-ipu6-dkms-git intel-ipu6-camera-bin intel-ipu6-camera-hal-git icamerasrc-git)

With the newest kernel I could immediately get a picture with qcam but I could not get it to work with either firefox or chromium.
With the following configuration I am finally able to use my webcam with nextcloud talk under chromium. The quality is not great, its greenish and a bit low on light. Its clearly missing calibration data. But its responsive and very usable.

laptop: Dell Latitude 7450
Kernel: 6.18.4-arch1-1
Sensor: INT3537
Camera name: hi556

dmesg |grep intel-ip6
intel-ipu6 0000:00:05.0: Found supported sensor INT3537:00

recognised by libcamera as: (leaving out the warnings here)

cam -l
Available cameras:
1: 'hi556' (\_SB_.PC00.LNK1)

Related packages I have installed:

local/pipewire-v4l2 1:1.4.9-2
local/v4l2loopback-dkms 0.15.3-1
local/v4l2loopback-utils 0.15.3-1
local/gst-plugin-libcamera 0.6.0-2
local/libcamera 0.6.0-2
local/libcamera-ipa 0.6.0-2
local/libcamera-tools 0.6.0-2
local/pipewire-libcamera 1:1.4.9-2
local/gstreamer 1.26.10-2

Create the following file:

cat /etc/modprobe.d/v4l2loopback.conf     
options v4l2loopback video_nr=60 card_label="v4l2_hi556_loopback" exclusive_caps=1

modprobe v4l2loopback

Now you've created a v4l2 loopback device /dev/video60

Use gstreamer to send the signal from your webcam to the v4l2loopback device:

gst-launch-1.0 libcamerasrc name="hi556" ! queue ! videoconvert ! video/x-raw,format=YUY2 ! v4l2sink name=v4l2sink-hi556 device=/dev/video60

I noticed that adding any other video settings here, like the resolution, would result in no video output
if all goes well you should see a counter going up (counting seconds of video stream sent to v4l2 sink.

Test it with ffplay:

ffplay /dev/video60

After this you should see a webcam device in chromium called: "v4l2_hi556_loopback" (don't let ffplay run in the background)

First I had "PipeWire Camera support" disabled in chrome://flags/
But now I've set it to "Default" again and its still working
Firefox does not see my v4l2loopback device for some reason.
obs works

edit
After using the camera for some time the image can start to flicker. And Gstreamer would show the following warnings:

WARNING: from element /GstPipeline:pipeline0/GstV4l2Sink:v4l2sink-hi556: A lot of buffers are being dropped.                                                  
Additional debug info:        
../gstreamer/subprojects/gstreamer/libs/gst/base/gstbasesink.c(3146): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/GstV4l2Sink:v4l2sink-hi556:        
There may be a timestamping problem, or this computer is too slow.

edit2
Was able to stop the flickering. See https://bbs.archlinux.org/viewtopic.php … 2#p2301912

Last edited by merijn (2026-06-18 13:15:31)

duzhuo · 2026-01-14 06:15:33

merijn wrote:

I've been able to get my webcam to work with libcamera, gstreamer, v4l2loopback, and chromium. I'll share the details here.
I'm not using the intel proprietary packages (intel-ipu6-dkms-git intel-ipu6-camera-bin intel-ipu6-camera-hal-git icamerasrc-git)
With the newest kernel I could immediately get a picture with qcam but I could not get it to work with either firefox or chromium.
With the following configuration I am finally able to use my webcam with nextcloud talk under chromium. The quality is not great, its greenish and a bit low on light. Its clearly missing calibration data. But its responsive and very usable.
laptop: Dell Latitude 7450
Kernel: 6.18.4-arch1-1
Sensor: INT3537
Camera name: hi556
dmesg |grep intel-ip6
intel-ipu6 0000:00:05.0: Found supported sensor INT3537:00
recognised by libcamera as: (leaving out the warnings here)
cam -l
Available cameras:
1: 'hi556' (\_SB_.PC00.LNK1)
Related packages I have installed:
local/pipewire-v4l2 1:1.4.9-2
local/v4l2loopback-dkms 0.15.3-1
local/v4l2loopback-utils 0.15.3-1
local/gst-plugin-libcamera 0.6.0-2
local/libcamera 0.6.0-2
local/libcamera-ipa 0.6.0-2
local/libcamera-tools 0.6.0-2
local/pipewire-libcamera 1:1.4.9-2
local/gstreamer 1.26.10-2
Create the following file:
cat /etc/modprobe.d/v4l2loopback.conf     
options v4l2loopback video_nr=60 card_label="v4l2_hi556_loopback" exclusive_caps=1
modprobe v4l2loopback
Now you've created a v4l2 loopback device /dev/video60
Use gstreamer to send the signal from your webcam to the v4l2loopback device:
gst-launch-1.0 libcamerasrc name="hi556" ! queue ! videoconvert ! video/x-raw,format=YUY2 ! v4l2sink name=v4l2sink-hi556 device=/dev/video60
I noticed that adding any other video settings here, like the resolution, would result in no video output
if all goes well you should see a counter going up (counting seconds of video stream sent to v4l2 sink.
Test it with ffplay:
ffplay /dev/video60
After this you should see a webcam device in chromium called: "v4l2_hi556_loopback" (don't let ffplay run in the background)
First I had "PipeWire Camera support" disabled in chrome://flags/
But now I've set it to "Default" again and its still working
Firefox does not see my v4l2loopback device for some reason.
obs works
edit
After using the camera for some time the image can start to flicker. And Gstreamer would show the following warnings:
WARNING: from element /GstPipeline:pipeline0/GstV4l2Sink:v4l2sink-hi556: A lot of buffers are being dropped.                                                  
Additional debug info:        
../gstreamer/subprojects/gstreamer/libs/gst/base/gstbasesink.c(3146): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/GstV4l2Sink:v4l2sink-hi556:        
There may be a timestamping problem, or this computer is too slow. 

Thanks for sharing. Its work on my Acer Swift SF314-512 with Debian sid.

schard · 2026-01-14 07:12:31

Mod note: @duzhuo please refrain from unnecessary full-quotes. Thank you.

platelminto · 2026-02-14 19:21:03

Got my webcam fully working on the X1 Carbon Gen 11 (i7-1355U, OV2740 sensor, kernel 6.18) using the in-tree IPU6 driver + libcamera. The default uncalibrated profile looks pretty bad so I put together a CCM tuning file that helps. Couldn't find one anywhere online so posting it here.

Install packages:

sudo pacman -S libcamera libcamera-ipa libcamera-tools gst-plugin-libcamera pipewire-libcamera

WirePlumber config — tells PipeWire to use libcamera instead of raw V4L2 (which only gives unusable bayer data):

mkdir -p ~/.config/wireplumber/wireplumber.conf.d

# ~/.config/wireplumber/wireplumber.conf.d/99-libcamera.conf
wireplumber.profiles = {
   main = {
      monitor.v4l2 = disabled
      monitor.libcamera = optional
   }
}

Firefox: set media.webrtc.camera.allow-pipewire to true in about:config, otherwise you get 30+ ipu6 entries in the camera dropdown instead of one usable device.

Tuning file — this is the main thing, without it libcamera falls back to uncalibrated.yaml and the image is washed out and green:

# /usr/share/libcamera/ipa/simple/ov2740.yaml
# SPDX-License-Identifier: CC0-1.0
%YAML 1.1
---
version: 1
algorithms:
  - BlackLevel:
  - Awb:
 # - Agc:
  - Adjust:
  - Ccm:
      ccms:
        - ct: 6500
          ccm: [ 2.25, -1.00, -0.25,
                -0.45,  1.35, -0.20,
                 0.00, -0.60,  1.60 ]

Boot race condition fix — WirePlumber often starts before the IPU6 driver is ready, so the camera doesn't show up until you manually restart it. This service handles it automatically:

# ~/.config/systemd/user/restart-wireplumber.service
[Unit]
Description=Restart WirePlumber to pick up libcamera device
After=wireplumber.service pipewire.service

[Service]
Type=oneshot
ExecStartPre=/usr/bin/sleep 5
ExecStart=/usr/bin/systemctl --user restart wireplumber

[Install]
WantedBy=default.target

systemctl --user daemon-reload
systemctl --user enable restart-wireplumber.service

Reboot after all of the above.

Notes:
- Still not perfect — there's a slight green cast that seems to come from the debayer stage before the CCM runs. The values aren't properly calibrated, just eyeballed, so if anyone can refine them please share.
- pacman -Syu will probably overwrite the tuning yaml when libcamera updates, keep a backup.

Edit: Based on other comments, I also removed Agc, since it fixed the awful flickering I was getting whenever my surroundings were too bright. I'm also going without the Ccm now, since I find the default washed out looked is a lil better than the aggressive pink that comes when it's too bright.

Last edited by platelminto (2026-02-26 12:20:33)

aljinovic · 2026-02-16 10:36:31

@platelminto your config helped a lot, thanks!

the `Ccm` part didn't work for Carbon X1 Gen10 with ov2740 (purple tint),
disabling Agc stops the flickering!

Here's the config that works well for me:

# /usr/share/libcamera/ipa/simple/ov2740.yaml
# SPDX-License-Identifier: CC0-1.0
%YAML 1.1
---
version: 1
algorithms:
  - BlackLevel:
  - Awb:
#  - Agc:
  - Adjust:

frnkq · 2026-02-23 18:05:41

Configs working for Thinkpad X1 Nano Gen 3, thank you @platelminto
The Tuning file was my missing piece, as the image was constantly flickering and with a very intrusive green tint.
I also had to disable Agc. This is my CCM, which is a bit brighter but still has a slight green tint.:

  - Ccm:
      ccms:
        - ct: 6500
          ccm: [ 3.05, -1.40, -0.15,
          -0.40,  2.70, -0.95,
          0.00, -1.50,  3.60 ]

halogene · 2026-03-06 09:13:28

Iruwen wrote:

Indeed, on 6.19rc3 with the Chromium PipeWire Camera support flag enabled at least https://webcamtests.com works to a degree, it's ugly but still. OVTI08F4/ov08x40 in a X1C G12.
/e: somehow after accessing the test page for a second time resolution increased and much of the noise disappeared, quality is kind of okay now.
https://i.ibb.co/wFmPCcqb/image.png

I'm running 6.19.6 with an OVTI08F4 here. Hopes were high that with 6.19 I would have ootb support for this sensor, but unfortunately this hasn't worked out in my case.

$ sudo dmesg | grep 0000:00:05
[    0.412704] pci 0000:00:05.0: [8086:7d19] type 00 class 0x048000 PCIe Root Complex Integrated Endpoint
[    0.412723] pci 0000:00:05.0: BAR 0 [mem 0x5020000000-0x5020ffffff 64bit]
[    0.412729] pci 0000:00:05.0: enabling Extended Tags
[    0.540007] pci 0000:00:05.0: Adding to iommu group 3
[   10.256446] pci 0000:00:05.0: Setting to D3hot
[   10.403382] intel-ipu6 0000:00:05.0: enabling device (0000 -> 0002)
[   10.412995] intel-ipu6 0000:00:05.0: Found supported sensor OVTI08F4:00
[   10.413091] intel-ipu6 0000:00:05.0: Connected 1 cameras
[   10.414191] intel-ipu6 0000:00:05.0: Sending BOOT_LOAD to CSE
[   10.461871] intel-ipu6 0000:00:05.0: Sending AUTHENTICATE_RUN to CSE
[   10.511117] intel-ipu6 0000:00:05.0: CSE authenticate_run done
[   10.511141] intel-ipu6 0000:00:05.0: IPU6-v4[7d19] hardware version 6

and

$ LIBCAMERA_LOG_LEVELS=0 cam --list
[0:37:18.816383767] [37620] DEBUG IPAModule ipa_module.cpp:333 ipa_ipu3.so: IPA module /usr/lib/libcamera/ipa/ipa_ipu3.so is signed
[0:37:18.816435750] [37620] DEBUG IPAManager ipa_manager.cpp:239 Loaded IPA module '/usr/lib/libcamera/ipa/ipa_ipu3.so'
[0:37:18.816466260] [37620] DEBUG IPAModule ipa_module.cpp:333 ipa_soft_simple.so: IPA module /usr/lib/libcamera/ipa/ipa_soft_simple.so is signed
[0:37:18.816483262] [37620] DEBUG IPAManager ipa_manager.cpp:239 Loaded IPA module '/usr/lib/libcamera/ipa/ipa_soft_simple.so'
[0:37:18.816507046] [37620] DEBUG IPAModule ipa_module.cpp:333 ipa_vimc.so: IPA module /usr/lib/libcamera/ipa/ipa_vimc.so is signed
[0:37:18.816522090] [37620] DEBUG IPAManager ipa_manager.cpp:239 Loaded IPA module '/usr/lib/libcamera/ipa/ipa_vimc.so'
[0:37:18.816528546] [37620]  INFO Camera camera_manager.cpp:340 libcamera v0.7.0
[0:37:18.816662647] [37621] DEBUG Camera camera_manager.cpp:74 Starting camera manager
[0:37:18.827348539] [37621] DEBUG DeviceEnumerator device_enumerator.cpp:267 New media device "intel-ipu6" created from /dev/media0
[0:37:18.827375600] [37621] DEBUG DeviceEnumerator device_enumerator_udev.cpp:111 Defer media device /dev/media0 due to 48 missing dependencies
[0:37:18.832671069] [37621] DEBUG DeviceEnumerator device_enumerator_udev.cpp:346 All dependencies for media device /dev/media0 found
[0:37:18.832681867] [37621] DEBUG DeviceEnumerator device_enumerator.cpp:295 Added device /dev/media0: intel-ipu6
[0:37:18.833095075] [37621] DEBUG Camera camera_manager.cpp:143 Found registered pipeline handler 'virtual'
[0:37:18.833112174] [37621] DEBUG DmaBufAllocator dma_buf_allocator.cpp:106 Failed to open /dev/dma_heap/linux,cma: No such file or directory
[0:37:18.833124121] [37621] DEBUG DmaBufAllocator dma_buf_allocator.cpp:106 Failed to open /dev/dma_heap/reserved: No such file or directory
[0:37:18.833130155] [37621] DEBUG DmaBufAllocator dma_buf_allocator.cpp:106 Failed to open /dev/dma_heap/system: Permission denied
[0:37:18.833147850] [37621] DEBUG DmaBufAllocator dma_buf_allocator.cpp:112 Using /dev/udmabuf
[0:37:18.833159934] [37621] DEBUG Virtual virtual.cpp:385 Configuration file not found, skipping virtual cameras
[0:37:18.833166216] [37621] DEBUG Camera camera_manager.cpp:143 Found registered pipeline handler 'vimc'
[0:37:18.833181277] [37621] DEBUG Camera camera_manager.cpp:143 Found registered pipeline handler 'uvcvideo'
[0:37:18.833187114] [37621] DEBUG Camera camera_manager.cpp:143 Found registered pipeline handler 'simple'
[0:37:18.833195477] [37621] DEBUG DeviceEnumerator device_enumerator.cpp:355 Successful match for media device "intel-ipu6"
[0:37:18.833204564] [37621]  INFO SimplePipeline simple.cpp:1899 No sensor found for /dev/media0
[0:37:18.833211496] [37621] DEBUG Camera camera_manager.cpp:143 Found registered pipeline handler 'ipu3'
Available cameras:

Do I still need to install the DKMS AUR packages for this sensor?

marmistrz · 2026-03-06 12:10:10

For me, the service restarting wireplumber was necessary to get the camera working. I also needed to able Agc to get proper colors (ov02c10). So lovely to have this working!

How does one tune the CCM for their own sensor?

Last edited by marmistrz (2026-03-06 12:20:13)

peter.g · 2026-03-06 23:15:04

My Dell XPS 16 ipu6 camera has been working with qcam since Linux kernel 6.16 landed last year, but the libcamera 0.6 --> 0.7 update last month broke it. I downgraded the affected packages but want to know a more permanent solution. Has anyone encountered this issue?

alba4k · 2026-03-10 20:02:45

I noticed that setting /usr/share/libcamera/ipa/simple/ov01a10.yaml as follows on a dell xps 9320 seems to disable the camera's ability to adjust exposure automatiaclly based on light amount (often resulting in extremely dark images in sub-optimal conditions)

# SPDX-License-Identifier: CC0-1.0
%YAML 1.1
---
version: 1
algorithms:
  - BlackLevel:
  - Awb:
  # - Agc:
  - Adjust:
  - Ccm:
      ccms:
        - ct: 6500
          ccm: [ 2.25, -1.00, -0.25,
                -0.45,  1.35, -0.20,
                 0.00, -0.60,  1.60 ]

does anyone know a fix?

halogene · 2026-03-12 10:30:28

Update: somehow after the last firmware updates my camera (OVTI08F4) started to work. For now. Let's see if that is persistent, it had been occasionally detected earlier too, lottery style. What is new is that I no longer have countless of ipu6 instances when trying to access the camera with a browser, I can actually use the camera now.

dmoebius · 2026-03-25 17:21:25

@halogene: "countless of ipu6 instances": if your browser is Firefox, try setting media.webrtc.camera.allow-pipewire to true in about:config.

dmoebius · 2026-03-25 17:25:31

@all: FYI: I found this blog article to be very helpful to understand the difference between the old and new camera stack:
https://jetm.github.io/blog/posts/ipu6- … a-on-linux
It helped me to remove several unnecessary dependencies, and solve the suspend/resume problem.
However, it didn't help me to fix the "green tint" problem, because I don't have the right CCM parameters for my ov02e10 camera driver.
Maybe switching to libcamera-git might help, let's see...

Michigan Forged · 2026-03-26 00:10:00

alba4k wrote:

I noticed that setting /usr/share/libcamera/ipa/simple/ov01a10.yaml as follows on a dell xps 9320 seems to disable the camera's ability to adjust exposure automatiaclly based on light amount (often resulting in extremely dark images in sub-optimal conditions)
# SPDX-License-Identifier: CC0-1.0
%YAML 1.1
---
version: 1
algorithms:
  - BlackLevel:
  - Awb:
  # - Agc:
  - Adjust:
  - Ccm:
      ccms:
        - ct: 6500
          ccm: [ 2.25, -1.00, -0.25,
                -0.45,  1.35, -0.20,
                 0.00, -0.60,  1.60 ]
does anyone know a fix?

I have the same computer, I notice at least on firefox it seems to adjust my brightness but yeah, the quality is pretty rough even with some of those adjustments. Would love a better solution because this is by far my biggest hangup using arch/cachy atm.

halogene · 2026-03-26 19:09:37

dmoebius wrote:

@halogene: "countless of ipu6 instances": if your browser is Firefox, try setting media.webrtc.camera.allow-pipewire to true in about:config.

I already had that setting active, but it still showed all the ipu6 instances nevertheless (provided the camera got recognized at all sporadically).

Now since 6.19.8 it works reliably, so far. Albeit with terrible quality, but well.

marmistrz · 2026-04-02 16:35:02

peter.g wrote:

My Dell XPS 16 ipu6 camera has been working with qcam since Linux kernel 6.16 landed last year, but the libcamera 0.6 --> 0.7 update last month broke it. I downgraded the affected packages but want to know a more permanent solution. Has anyone encountered this issue?

For me the camera worked on March 6, but no longer does. And that was already 0.7.0. (ov02c10)

I'm puzzled

nicolassilvar · 2026-04-11 21:37:01

I have a Lenovo X1 Nano with a OV2740 Camera (https://wiki.archlinux.org/title/Lenovo … no_(Gen_2))

I was finally able to get the cam working with the help of Claude Code Agent, below a summary of what the LLM did in case its helpful to anyone

* [GUIDE] Getting IPU6 webcam working on Lenovo X1 Nano (and similar ThinkPads) for Zoom/Meet

*Hardware:* Lenovo X1 Nano | Sensor: OV2740 (ipu6) | Kernel: 6.19.11-arch1-1

The ipu6 camera doesn't expose a standard v4l2 capture device, so apps like Zoom and Google Meet
can't use it directly. The solution is to bridge libcamera → v4l2loopback using GStreamer.

* 1. Required packages

#+begin_src bash
sudo pacman -S gstreamer gst-plugins-base gst-plugins-good gst-plugin-libcamera v4l2loopback-dkms v4l-utils
#+end_src

* 2. Load v4l2loopback at boot

#+begin_src bash
echo "v4l2loopback" | sudo tee /etc/modules-load.d/v4l2loopback.conf
echo 'options v4l2loopback devices=1 video_nr=0 card_label="Dummy video device"' | sudo tee /etc/modprobe.d/v4l2loopback.conf
#+end_src

Reboot or load manually: ~sudo modprobe v4l2loopback devices=1 video_nr=0~

* 3. Verify libcamera detects the camera

#+begin_src bash
cam --list
#+end_src

Should show something like ~_SB_.PC00.LNK1~ (Internal front camera).

* 4. Create a systemd user service for the bridge

File: =~/.config/systemd/user/camera-bridge.service=

#+begin_src ini
[Unit]
Description=libcamera to v4l2loopback bridge
After=graphical-session.target

[Service]
ExecStart=gst-launch-1.0 libcamerasrc ! video/x-raw,width=1280,height=720,framerate=30/1 ! videoconvert ! video/x-raw,format=YUY2 ! v4l2sink device=/dev/video0 sync=false
Restart=on-failure

[Install]
WantedBy=graphical-session.target
#+end_src

Enable it:

#+begin_src bash
systemctl --user daemon-reload
systemctl --user enable --now camera-bridge.service
#+end_src

* 5. Select the device in Zoom/Meet

- In Zoom: Settings → Video → select *"Dummy video device (0x0000)"*
- In Google Meet: Settings → Video → same device.

* Notes

- ~sync=false~ in the pipeline is important — without it the stream may stall
- Only one app can use libcamera at a time — if another app (e.g. Kamoso) has the camera open, the bridge won't start
- ~v4l2-relayd~ does not work on this setup — use gst-launch directly
- To debug: ~systemctl --user status camera-bridge.service~

adubovskoy · 2026-04-23 10:55:02

That's my fork of gc2607-v4l2-driver: https://github.com/adubovskoy/gc2607-v4l2-driver
It's for Huawei Matebook X Pro 2024. Tested and works.

soragoto · 2026-05-11 05:37:44

I got the OV02C10 camera working on a Dell XPS 13 9340 with Arch Linux.

My setup:

Linux 7.0.3
KDE Plasma / Wayland
OVTI02C1:00 -> ov02c10

AUR packages used:

intel-ipu6-dkms-git
intel-ipu6-camera-bin
intel-ipu6-camera-hal-git
icamerasrc-git
v4l2loopback-dkms
v4l2-relayd

The camera works through Intel IPU6 HAL + icamerasrc. I then bridge it to a normal webcam device with v4l2loopback.

I had to make several local changes.

1. In /etc/camera/ipu6epmtl/libcamhal_profile.xml, I limited availableSensors to:

ov02c10-uf-4

2. In /etc/camera/ipu6epmtl/sensors/ov02c10-uf.xml, I hardcoded the media entity names for my machine:

ov02c10 17-0036
Intel IPU6 CSI2 4
Intel IPU6 ISYS Capture 32

3. I had to add uaccess for /dev/ipu-psys0. Without this, icamerasrc failed as a normal user with:

Failed to open PSYS, error: Permission denied

My udev rule is:

SUBSYSTEM=="intel-ipu6-psys", TAG+="uaccess"

4. After a reboot, the camera broke again because the sensor entity name changed:

ov02c10 17-0036 -> ov02c10 16-0036

The CSI and capture entity names stayed the same, but the sensor subdev name changed. Since the HAL was doing exact matching, it failed to find the sensor subdev.

I fixed this with a small ipu6-camera-hal patch. See the PR below for details.

Related PR:

https://github.com/intel/ipu6-camera-hal/pull/173

Detailed notes are here, but they are written in Chinese:

https://soragoto.io/posts/xps13-9340/camera/

Maybe this helps other OV02C10 / XPS 13 9340 users.

merijn · 2026-06-18 13:14:25

A little update on my setup described in post: https://bbs.archlinux.org/viewtopic.php … 1#p2282711

I have been able to fix the flickering issue by making two changes
1: Change the gstreamer command I use to:

gst-launch-1.0 libcamerasrc name=hi556 ! video/x-raw,framerate=15/1 ! queue leaky=downstream max-size-buffers=2 ! videoconvert ! video/x-raw,format=NV12,framerate=15/1 ! v4l2sink name=v4l2sink-hi556 device=/dev/video60 sync=false

changing the resolution somehow always resulted in a blank/white image. So I keep that the same.

2: Created a hi556 calibration file and disabled Agc. Also changed the contrast and gamma to slightly improve the overexposure.

cat /usr/share/libcamera/ipa/simple/hi556.yaml
%YAML 1.1
---
version: 1
algorithms:
  - BlackLevel:
  - Awb:
  - Adjust:
  - Agc:
      enabled: false

controls:
  - Contrast: 0.7       # reduces harsh highlights, default is 1.0
  - Gamma: 2.0          # higher gamma darkens bright areas more than shadows

I'm now able to use my webcam for work. The image quality is still bad but its workable

Last edited by merijn (2026-06-18 13:28:50)

alba4k · 2026-06-24 21:35:22

For some reason it looks like libcamera-ipu6 is now required for ov01a10? how come? ..it used to work?

Last edited by alba4k (2026-06-24 21:36:54)

95A31 · 2026-07-17 20:59:37

Hi, I just wanna share how I made my webcam works. The whole thing was done with the help of Claude, as well as the following guide. Corrections are welcome.

Intel IPU6 (OV02C10) Webcam on Arch / EndeavourOS
Getting full hardware-ISP quality (factory-calibrated, what Windows/Dell-Ubuntu give you) out of the IPU6 camera.

Tested: Dell XPS 13 9340 · OV02C10 sensor · IPU6 Meteor Lake · EndeavourOS · kernels 7.1.2 and 7.1.3-arch1-3 (survived the bump via DKMS).

Result: /dev/video60 = Intel MIPI Camera, works in Firefox/Zoom/VLC/Teams/OBS, on-demand (LED only lights when an app opens it), boot-persistent, suspend-safe.

Info: There are two paths. Pick one, never mix.

libcamera + software ISP: Open source, near-zero setup on kernel ≥ 6.10. But there's no factory calibration, framerate dips, processed on your CPU. Most guides and the "Galaxy Book"-style fix scripts install this.
Intel HAL + hardware ISP: Real calibration, hardware processing, proper color, much better image quality.

The following is for option 2: Intel HAL + hardware ISP. Mixing them means two stacks contending for the sensor and shadowing each other's libraries.

Part 1 — Quick Installation
1.1 Packages

sudo pacman -S —needed base-devel git v4l2loopback-dkms v4l2loopback-utils v4l-utils
pamac build intel-ipu6-camera-bin intel-ipu6-dkms-git icamerasrc-git v4l2-relayd

1.2 Build the HAL (patch required)

git clone https://aur.archlinux.org/intel-ipu6-camera-hal-git.git
cd intel-ipu6-camera-hal-git

Add this prepare() to the PKGBUILD:

prepare() {
    cd "$srcdir/$_pkgname"
    find . -name CMakeLists.txt -exec sed -i 's/-Werror//g' {} +
    find . -name CMakeLists.txt -exec sed -i 's/-D_FORTIFY_SOURCE=[0-9]//g' {} +
    cd "$srcdir"
}

and these two lines at the top of build():

export CFLAGS="${CFLAGS//-D_FORTIFY_SOURCE=2/} -Wno-error"
export CXXFLAGS="${CXXFLAGS//-D_FORTIFY_SOURCE=2/} -Wno-error"

Then makepkg -si. Confirm: ls -l /usr/lib/libcamhal.so* must resolve to a real file.

1.3 Smoke-test the hardware ISP

sudo modprobe intel-ipu6-psys        # usually auto-loads; check `lsmod | grep psys`
ls -l /dev/ipu-psys0                 # MUST exist
sudo -E gst-launch-1.0 icamerasrc buffer-count=7 ! \
    video/x-raw,format=NV12,width=1280,height=720 ! videoconvert ! ximagesink

live picture here means the hard part is done.

1.4 Relay config

sudo tee /etc/default/v4l2-relayd > /dev/null << 'EOF'
DEVICE=/dev/video60
CARD_LABEL="Intel MIPI Camera"
VIDEOSRC="icamerasrc buffer-count=7"
FORMAT=NV12
WIDTH=1280
HEIGHT=720
FRAMERATE=30/1
EOF

sudo tee /etc/modprobe.d/v4l2loopback.conf > /dev/null << 'EOF'
options v4l2loopback devices=0
EOF

1.5 Readiness script

sudo tee /usr/local/bin/ipu6-camera-ready > /dev/null << 'EOF'
#!/bin/sh
# Exits 0 only when PSYS is up, the sensor is in the media graph, and a
# correctly-labeled v4l2loopback device exists. Triggered by udev.
set -u
LOOPBACK_DEV=/dev/video60
LOOPBACK_LABEL="Intel MIPI Camera"

log() { echo "ipu6-camera-ready: $*"; }
labeled_loopback_exists() {
    grep -qlx "$LOOPBACK_LABEL" /sys/devices/virtual/video4linux/*/name 2>/dev/null
}

if [ ! -e /dev/ipu-psys0 ]; then
    log "waiting for PSYS…"
    i=0
    while [ $i -lt 60 ]; do
        [ -e /dev/ipu-psys0 ] && break
        sleep 0.5; i=$((i + 1))
    done
fi
[ -e /dev/ipu-psys0 ] || { log "FAIL: /dev/ipu-psys0 never appeared"; exit 1; }

[ -e /usr/lib/libcamhal.so ] || { log "FAIL: libcamhal.so missing"; exit 1; }

log "waiting for sensor in media graph…"
i=0; ready=0
while [ $i -lt 60 ]; do
    for m in /dev/media*; do
        [ -e "$m" ] || continue
        media-ctl -d "$m" -p 2>/dev/null | grep -qi 'ov02c10' && { ready=1; break; }
    done
    [ "$ready" -eq 1 ] && break
    sleep 0.5; i=$((i + 1))
done
[ "$ready" -eq 1 ] || { log "WARN: sensor not confirmed; settling"; sleep 5; }

if labeled_loopback_exists; then
    log "loopback already present and labeled"
else
    log "creating labeled loopback at $LOOPBACK_DEV…"
    systemctl stop 'v4l2-relayd@0.service' 2>/dev/null
    modprobe -r v4l2loopback 2>/dev/null
    modprobe v4l2loopback || { log "FAIL: cannot load v4l2loopback"; exit 1; }
    v4l2loopback-ctl add -n "$LOOPBACK_LABEL" -x 1 "$LOOPBACK_DEV" \
        || { log "FAIL: v4l2loopback-ctl add failed"; exit 1; }
fi

i=0
while [ $i -lt 30 ]; do
    [ -c "$LOOPBACK_DEV" ] && break
    sleep 0.2; i=$((i + 1))
done
[ -c "$LOOPBACK_DEV" ] || { log "FAIL: $LOOPBACK_DEV never appeared"; exit 1; }
labeled_loopback_exists || { log "FAIL: loopback not labeled '$LOOPBACK_LABEL'"; exit 1; }

log "ready: PSYS up, $LOOPBACK_DEV labeled '$LOOPBACK_LABEL'"
exit 0
EOF
sudo chmod +x /usr/local/bin/ipu6-camera-ready

1.6 Units + udev trigger

sudo tee /etc/systemd/system/ipu6-camera-ready.service > /dev/null << 'EOF'
[Unit]
Description=Prepare IPU6 camera stack (PSYS + labeled v4l2loopback)
After=systemd-modules-load.service
Upholds=v4l2-relayd@0.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/bin/ipu6-camera-ready

[Install]
WantedBy=multi-user.target
EOF

sudo mkdir -p /etc/systemd/system/v4l2-relayd@.service.d
sudo tee /etc/systemd/system/v4l2-relayd@.service.d/10-restart.conf > /dev/null << 'EOF'
[Service]
RestartSec=5
EOF

sudo tee /etc/udev/rules.d/99-ipu6-camera.rules > /dev/null << 'EOF'
ACTION=="add", KERNEL=="ipu-psys0", TAG+="systemd", ENV{SYSTEMD_WANTS}="ipu6-camera-ready.service"
EOF

sudo systemctl daemon-reload
sudo udevadm control —reload-rules
sudo systemctl enable ipu6-camera-ready.service

1.7 Kill the libcamera duplicate

sudo tee /etc/wireplumber/wireplumber.conf.d/50-disable-libcamera.conf > /dev/null << ‘EOF’
wireplumber.profiles = {
  main = {
    monitor.libcamera = disabled
  }
}
EOF
systemctl —user restart wireplumber pipewire

1.8 Reboot and verify

sudo reboot

systemctl is-active ipu6-camera-ready.service          # active
systemctl is-active ‘v4l2-relayd@0.service’            # active
systemctl show ‘v4l2-relayd@0.service’ -p UpheldBy     # UpheldBy=ipu6-camera-ready.service
v4l2-ctl -d /dev/video60 —info | grep ‘Card type’     # Intel MIPI Camera
wpctl status | grep -iE ‘MIPI|ov02’                    # only Intel MIPI Camera

Resilience check — the relay should come back on its own:

sudo systemctl stop ‘v4l2-relayd@0.service’; sleep 8; systemctl is-active ‘v4l2-relayd@0.service’

Part 2 — Design Choices & Pitfalls
Why each piece is the way it is, and what bites you if you deviate. Every pitfall below was hit for real.

2.1 Why the proprietary path at all — and why “obsolete” is a lie
- Choice: use Intel’s out-of-tree PSYS + HAL rather than libcamera.
- The trap: intel-ipu6-dkms-git’s AUR page says ”This package is obsolete! Linux kernel 6.10 onwards now has built-in IPU6 drivers and this package will no longer work. Uninstall it.” Its maintainer also wrote ”IPU6 is so horrendous I’ve basically given up on it.” Intel’s own repos target kernel 6.12/Ubuntu 24.04, and patch/v7.0/in-tree-build/ is empty — no PSYS build workaround for kernel 7. Every signal says stop.
- The reality: those warnings refer to the sensor and ISYS drivers, which are in-tree now. PSYS never went in-tree — Intel keeps the hardware-ISP algorithms proprietary. It’s a separate module, still required, and the DKMS package still builds it fine on 7.x despite the missing patch directory.
- How to check for yourself rather than trust the warning:
  sudo find /usr/lib/modules/$(uname -r) /var/lib/dkms -iname ‘*psys*’
  sudo find /var/lib/dkms/ipu6-drivers -name make.log -exec tail -20 {} \;;
  If you see LD [M] …/psys/intel-ipu6-psys.ko and exit code: 0, it built. That single check is what this entire guide rests on.
2.2 The HAL build patch
- Choice: strip -Werror and the fortify redefinition.
- Pitfall: makepkg injects -D_FORTIFY_SOURCE=2; the HAL’s CMake sets it too; GCC warns about the redefinition; -Werror promotes it to fatal. Build dies at ~0% on I3AControlFactory.cpp.
- Pitfall: old AUR comments suggest patches for intel-ipu6ep-camera-hal-git (the deprecated Alder-Lake-only package) with different CMake flags like -DIPU_VER. Don’t apply them — the current unified package uses -DIPU_VERSIONS=”ipu6;ipu6ep;ipu6epmtl” and those old diffs will break it differently.
- Watch for: if stripping -Werror reveals a genuine C++ error deeper in (not a promoted warning), you’ve hit a real toolchain incompatibility that needs source patches nobody has written. That’s the point to stop.
2.3 PSYS doesn’t need forcing — but check
- Choice: rely on modalias auto-loading.
- Pitfall: the obvious move is /etc/modules-load.d/ipu6-psys.conf. Usually unnecessary — the kernel matches the PCI device and loads intel_ipu6_psys on its own. Verify with lsmod | grep psys after a clean boot before adding anything.
- Pitfall: /dev/ipu-psys0 existing does not mean the stack is usable — see 2.6.
- Note: early dmesg shows deferred probe pending: intel-ipu6: IPU6 bridge init failed. That’s normal; it resolves later in boot. Don’t chase it.
2.4 Why a relay at all
- Choice: bridge icamerasrc → v4l2loopback via v4l2-relayd.
- Why: icamerasrc is a GStreamer element. Firefox, Zoom, VLC, Teams, OBS don’t speak GStreamer — they want a /dev/video* node. The relay runs the HAL pipeline and writes frames into a virtual camera every app can open.
- Bonus: v4l2-relayd is on-demand — it only runs the pipeline when an app opens the device, so the camera LED stays dark and CPU stays idle otherwise. Don’t replace it with an always-on gst-launch service; you'd lose that and light your LED 24/7. (Verify with: LED off at idle, ps aux | grep -c ‘icamerasrc’ → 1, the daemon itself.)
- Nice detail: the shipped unit already has DeviceAllow=char-intel-ipu6-psys — this package was written with IPU6 in mind.
2.5 The device-number trap — use video60, not video0
- Choice: pin the loopback to /dev/video60.
- Pitfall: the obvious move is video0 (apps default to it). Don’t. The in-tree ISYS driver creates ~48 raw nodes that claim video0 upward, and their numbering shifts between boots (I saw 41 nodes one boot, 48 the next). Ask for video0 and you’ll either get failed to create device: File exists, or get silently bumped elsewhere while a raw ipu6 node squats at video0 — apps then find garbage where the camera should be. Symptom: v4l2-ctl -d /dev/video0 —info reports Card type: ipu6 at 3840x2160.
- Pitfall: options v4l2loopback devices=1 auto-creates an unlabeled “Dummy” device at load that collides with the one you want. Use devices=0 and let the script create exactly one, explicitly.
- Note: DEVICE= in /etc/default/v4l2-relayd is nearly decorative — the unit’s ExecStart greps /sys/devices/virtual/video4linux/*/name for CARD_LABEL. The label is what matters; keep DEVICE= accurate anyway.
2.6 Why udev triggers it, not a boot target
- Choice: ACTION==”add”, KERNEL==”ipu-psys0”, TAG+=”systemd”, ENV{SYSTEMD_WANTS}=”…”.
- Why: the kernel tells you when PSYS exists. Hanging the service off basic.target means guessing whether PSYS is there yet — the device event is the readiness signal, so the ordering problem disappears structurally.
- Pitfall: TAG+=”systemd” is mandatory. Per systemd.device(5), SYSTEMD_WANTS “is not taken into account unless the device is tagged with the systemd tag” — without it the rule silently does nothing.
- Pitfall: systemd “will only act on Wants= when a device first becomes active”. Testing with udevadm trigger fires udev but not necessarily the systemd side. Only a real reboot proves this.
2.7 Why `sleep 5` had to go
- Choice: poll media-ctl for the sensor instead of sleeping.
- Why: PSYS appears before the IPU6 stack is usable — the kernel does a deferred probe and the sensor lands in the media graph a moment later. The original design covered this with sleep 5: a magic number that’s a guess, breaks if a future kernel is slower, and wastes time if it’s faster.
  Polling for the actual condition (media-ctl -d /dev/mediaN -p | grep ov02c10) returns in 0s on this hardware and self-adjusts elsewhere.
- Pitfall: don’t hard-fail if media-ctl is missing or the graph names things differently on other hardware — fall back to a settle delay. Insurance, not a tripwire.
2.8 Why two units — you cannot merge them
- Choice: a separate unsandboxed ipu6-camera-ready.service does privileged setup; the relay only relays.
- This looks redundant. It is not optional. v4l2-relayd@.service ships with:
  CapabilityBoundingSet= # empty — NO capabilities
  DevicePolicy=closed
  DeviceAllow=char-video4linux
  DeviceAllow=char-intel-ipu6-psys
- Pitfall (tested): folding modprobe + v4l2loopback-ctl add into the relay’s own ExecStartPre fails with:
  unable to open control device ‘/dev/v4l2loopback’: Operation not permitted
  No CAP_SYS_MODULE, and /dev/v4l2loopback isn’t in the DeviceAllow list. The relay deliberately cannot load modules or create loopbacks. Merging means gutting the packager’s security hardening to save one file. Bad trade. The split is forced by the sandbox.
2.9 `Upholds=`, not `Wants=` — the subtle one
- Choice: Upholds=v4l2-relayd@0.service in the ready unit.
- Pitfall (cost several reboots): Wants= looks right and fails silently. Per systemd.unit(5), if the wanted unit “cannot be added to the transaction, this has no impact on the validity of the transaction as a whole, and this unit will still be started.” Observed result: ready runs perfectly, relay gets no start job at all, nothing logged in either journal, systemctl show … -p ConditionResult shows a stale no. Nothing tells you it was dropped.
- Why Upholds= works: it’s “similar to Wants=, but as long as this unit is up, all units listed are started whenever found to be inactive or failed, and no job is queued for them.” No job = nothing to silently drop. And the continuous effect restarts the relay for free if it dies — Restart=always becomes redundant.
- Pitfall Mechanism: RemainAfterExit=yes is load-bearing. Upholds= only holds while the unit is up; a Type=oneshot without it goes inactive the instant the script exits, and the relationship evaporates.
- Pitfall — the deadlock: using ExecStartPost=/usr/bin/systemctl start v4l2-relayd@0.service while the relay has After=ipu6-camera-ready.service hangs forever: systemctl start blocks on the relay → relay waits for ready → ready can’t finish. You’ll see ready stuck activating with └─ /usr/bin/systemctl start v4l2-relayd@0.service in its CGroup. If you must use ExecStartPost, add —no-block.
- Pitfall: do not add After=ipu6-camera-ready.service to the relay alongside Upholds=. It creates an unresolvable transaction and the relay’s job gets silently dropped. Upholds= only fires once the upholder is active — the ordering is already implicit.
- Verify it registered: systemctl show ‘v4l2-relayd@0.service’ -p UpheldBy → UpheldBy=ipu6-camera-ready.service. Empty means it didn’t take.
2.10 Hiding the duplicate and the clutter
- Choice: disable libcamera in WirePlumber; accept the raw-node clutter.
- Why disable libcamera: it independently exposes the sensor as an ov02c10 PipeWire source — the worse Path-A camera. It’s not just a cosmetic duplicate: both paths read the same ISYS nodes, so picking it can contend with your HAL stack for the sensor.
- Pitfall: matching by node name doesn’t work — those nodes are named v4l2_input.pci-0000_00_05.0.x and ipu6 only appears in the description. Disabling the whole libcamera monitor via wireplumber.profiles is cleaner and survives.
- Accept this: VLC and other raw-V4L2 apps will always list ~48 ipu6 devices. They enumerate /dev/video* directly, ignoring PipeWire rules — and they’ll list nodes even with permissions stripped (I tried TAG-=”uaccess”, GROUP=”root”, MODE=”0660” — the nodes became inaccessible but VLC still showed them). They can’t be removed without unloading the driver your camera needs. Pick “Intel MIPI Camera” and move on; this is not worth fighting.
2.11 Gotchas that will waste your afternoon
- Firefox caches its camera list. If it “stops seeing” the camera, pkill firefox and reopen before debugging anything else. This wasted time twice.
- csi2-4 error: Frame sync error floods dmesg constantly. Benign. Ignore.
- Upside-down image? Mine was inverted mid-setup and came up correct after a full reboot. Try that before adding videoflip method=rotate-180. Left/right mirroring in self-view is normal — the far end sees you correctly; do not add a horizontal flip.
- v4l2-relayd.service (non-templated) is ExecStart=/bin/true. That’s correct — it’s a grouping anchor. The real worker is the templated v4l2-relayd@0.service. Enabling the wrong one does nothing.
- Kernel updates: survived 7.1.2 → 7.1.3 with DKMS rebuilding PSYS automatically. If a kernel ever breaks the build you silently lose the hardware ISP — check /var/lib/dkms/ipu6-drivers/*/*/log/make.log.
- Back up your config. Reconstructing the patched PKGBUILD and unit files from scratch is genuinely painful.

Arch Linux

#176 2026-01-12 05:50:55

Re: How to use the IPU6 webcam with kernel 6.10+?

#177 2026-01-12 19:53:31

Re: How to use the IPU6 webcam with kernel 6.10+?

#178 2026-01-14 06:15:33

Re: How to use the IPU6 webcam with kernel 6.10+?

#179 2026-01-14 07:12:31

Re: How to use the IPU6 webcam with kernel 6.10+?

#180 2026-02-14 19:21:03

Re: How to use the IPU6 webcam with kernel 6.10+?

#181 2026-02-16 10:36:31

Re: How to use the IPU6 webcam with kernel 6.10+?

#182 2026-02-23 18:05:41

Re: How to use the IPU6 webcam with kernel 6.10+?

#183 2026-03-06 09:13:28

Re: How to use the IPU6 webcam with kernel 6.10+?

#184 2026-03-06 12:10:10

Re: How to use the IPU6 webcam with kernel 6.10+?

#185 2026-03-06 23:15:04

Re: How to use the IPU6 webcam with kernel 6.10+?

#186 2026-03-10 20:02:45

Re: How to use the IPU6 webcam with kernel 6.10+?

#187 2026-03-12 10:30:28

Re: How to use the IPU6 webcam with kernel 6.10+?

#188 2026-03-25 17:21:25

Re: How to use the IPU6 webcam with kernel 6.10+?

#189 2026-03-25 17:25:31

Re: How to use the IPU6 webcam with kernel 6.10+?

#190 2026-03-26 00:10:00

Re: How to use the IPU6 webcam with kernel 6.10+?

#191 2026-03-26 19:09:37

Re: How to use the IPU6 webcam with kernel 6.10+?

#192 2026-04-02 16:35:02

Re: How to use the IPU6 webcam with kernel 6.10+?

#193 2026-04-11 21:37:01

Re: How to use the IPU6 webcam with kernel 6.10+?

#194 2026-04-23 10:55:02

Re: How to use the IPU6 webcam with kernel 6.10+?

#195 2026-05-11 05:37:44

Re: How to use the IPU6 webcam with kernel 6.10+?

#196 2026-06-18 13:14:25

Re: How to use the IPU6 webcam with kernel 6.10+?

#197 2026-06-24 21:35:22

Re: How to use the IPU6 webcam with kernel 6.10+?

#198 2026-07-17 20:59:37

Re: How to use the IPU6 webcam with kernel 6.10+?

Board footer