Open bk2204 opened 2 years ago
Thanks @Ronan0912
i tried that. removed the firmware and reinstalled all the packages (fireware
was a typo ;-P)
sudo rm -fr /usr/lib/firmware/intel/ipu6*
sudo apt install linux-firmware --reinstall
sudo apt install linux-modules-ipu6-generic-hwe-22.04 linux-modules-ivsc-generic-hwe-22.04 --reinstall
sudo apt install v4l2loopback-dkms v4l2-relayd v4l-utils --reinstall
sudo apt install libcamhal0 --reinstall
i now have three files in the firmware folder
-rw-r--r-- 1 root root 466944 9月 22 22:10 /usr/lib/firmware/intel/ipu6ep_fw.bin
-rw-r--r-- 1 root root 466944 9月 22 22:10 /usr/lib/firmware/intel/ipu6epmtl_fw.bin
-rw-r--r-- 1 root root 471040 9月 22 22:10 /usr/lib/firmware/intel/ipu6_fw.bin
rebooted and the camera is detected/listed in apps like zoom or skype but still shows just a black canvas.
any further hints would be greatly appreciated.
@fvbock
Have tried to reboot twice like @lukemarsden did? Have tried again with the firmware from intel's git repository after rebooted twice?
Can you provide kernel logs for both firmware when starting a webcam session:
$ sudo dmesg | grep ipu
?
Can you provide the logs for v4l2-relay service when starting a webcam session:
$ sudo systemctl status v4l2-relayd.service
?
What is you kernel version?
@Ronan0912 Thanks!
I will try the double reboot and grep for logs - will post those later.
Kernel version is 6.2.0-34-generic #34~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Sep 7 13:12:03 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
Does not work on Dell XPS 13 Plus 9320 Fedora 39 atm. But great efforts here, thanks all for the contribs.
Update: this https://github.com/intel/ipu6-drivers/issues/22#issuecomment-1742769010 it works on 6.4
I have one of those, and webcam is working here. But I've installed it on Gentoo, so I haven't followed the same process...5. okt. 2023 23:42 skrev Santiago Bernhardt @.***>: Does not work on Dell XPS 13 Plus 9320 Fedora 39 atm. But great efforts here, thanks all for the contribs
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>
Works perfectly fine for me on the same hardware, with Fedora 37.
Santiago: "Does not work" is not useful information if you actually want help. Its also not useful information even if you don't want help.
On Thu, Oct 5, 2023 at 11:11 PM Mads @.***> wrote:
I have one of those, and webcam is working here. But I've installed it on Gentoo, so I haven't followed the same process...5. okt. 2023 23:42 skrev Santiago Bernhardt @.***>: Does not work on Dell XPS 13 Plus 9320 Fedora 39 atm. But great efforts here, thanks all for the contribs
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>
— Reply to this email directly, view it on GitHub https://github.com/intel/ipu6-drivers/issues/22#issuecomment-1750036368, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAARLSMNAT3MVBGEGMUCLS3X56OJDAVCNFSM5ZN5CZE2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZVGAYDGNRTGY4A . You are receiving this because you were mentioned.Message ID: @.***>
Fedora 39 comes with kernel 6.5.5 fresh install added the testing packages follwing this
https://hansdegoede.livejournal.com/27276.html
The camera is not available in web firefox testing.
There is nothing on dmesg or logs.
Fresh install of Fedora 38 same kernel but for f38 same testing packages the camera works.
Not sure what further details can I provide. Is more of a heads up of fedora beta might have some breaking changes impacting this that I don't understand at first sight.
Ask me and ill try to provide further details/logs/proof.
Did anyone try to get things to work on Ubuntu 23.10 by chance?
@scottkosty haven't upgraded yet but was able to get it running on 23.04, you will probably have to enable the ppa repository
ppa:oem-solutions-group/intel-ipu6 and then modify it to use the last available distro (jammy). After that you can install the HAL library under additional drivers. It is very buggy but I was able to get it to work. Occasionally it does lock up the camera and only shows a black screen. When that happens, the only way to unlock the camera is using
sudo service v4l2-relayd restart
@omriasta thanks for those details!
About those of you who are having trouble with the Fedora packages. I can confirm that they have stopped working on some models (seems to be mostly on Dell models).
I have prepared a fixed akmod-intel-ipu6 for this. This is still finding its way into rpmfusion updates-testing you can download and install it directly yourself by downloading akmod-intel-ipu6-....x86_64.rpm
from here:
And then no the commandline, from the directory where you have downloaded the file run:
sudo rpm -Uvh akmod-intel-ipu6*.rpm
I'm not sure if this will start a build of the updated kmod right away or if that only happens on the next boot. To make sure you have the new version of the module build and loaded please reboot twice and then try your camera again.
Thanks @jwrdegoede ! FWIW, (and I'm not sure it was meant to) this doesn't seem to improve the situation in https://github.com/intel/ipu6-drivers/issues/187
@jwrdegoede Thanks for the packaging to fedora, but I've a problem with dell 9440:
out 14 08:31:48 pluto v4l2-relayd[40422]: Registering meta implementation 'GstCamerasrcMeta' without init function
out 14 08:31:48 pluto kernel: intel-ipu6-isys intel-ipu6-isys0: no pipe or streaming, adding to incoming
out 14 08:31:48 pluto kernel: intel-ipu6-isys intel-ipu6-isys0: no pipe or streaming, adding to incoming
out 14 08:31:48 pluto kernel: intel-ipu6-isys intel-ipu6-isys0: no pipe or streaming, adding to incoming
out 14 08:31:48 pluto kernel: intel-ipu6-isys intel-ipu6-isys0: stream on ov02c10 19-0036
out 14 08:31:53 pluto sh[40422]: [10-14 08:31:48.316] CamHAL[INF] aiqb file name OV02C10_1BG203N3_ADL.aiqb
out 14 08:31:53 pluto sh[40422]: [10-14 08:31:48.316] CamHAL[INF] aiqb file name OV02C10_1BG203N3_ADL.aiqb
out 14 08:31:53 pluto sh[40422]: [10-14 08:31:48.316] CamHAL[INF] aiqb file name OV02C10_1SG204N3_ADL.aiqb
out 14 08:31:53 pluto sh[40422]: [10-14 08:31:48.316] CamHAL[INF] aiqb file name OV02C10_1SG204N3_ADL.aiqb
out 14 08:31:53 pluto sh[40422]: [10-14 08:31:48.316] CamHAL[INF] aiqb file name OV02C10_CIFME14_ADL.aiqb
out 14 08:31:53 pluto sh[40422]: [10-14 08:31:48.316] CamHAL[INF] aiqb file name OV02C10_CIFME14_ADL.aiqb
out 14 08:31:53 pluto sh[40422]: [10-14 08:31:48.825] CamHAL[ERR] Poll: Device node fd 22 poll timeout.
out 14 08:31:53 pluto sh[40422]: [10-14 08:31:48.926] CamHAL[ERR] Poll: Device node fd 22 poll timeout.
out 14 08:31:53 pluto sh[40422]: [10-14 08:31:49.26] CamHAL[ERR] Poll: Device node fd 22 poll timeout.
out 14 08:31:53 pluto sh[40422]: [10-14 08:31:49.126] CamHAL[ERR] Poll: Device node fd 22 poll timeout.
I've this packages:
➜ rpm -qa | grep ipu6
ipu6-camera-bins-0.0-8.20230208git276859f.fc39.x86_64 from RPM Fusion
ipu6-camera-hal-0.0-15.20230208git884b81a.fc39.x86_64 from RPM Fusion
kmod-intel-ipu6-6.5.5-300.fc39.x86_64-0.0-8.20230622git8e41080.fc39.x86_64 from (none)
kmod-intel-ipu6-6.5.4-300.fc39.x86_64-0.0-8.20230622git8e41080.fc39.x86_64 from (none)
akmod-intel-ipu6-0.0-9.20230622git8e41080.fc39.x86_64 from RPM Fusion
kmod-intel-ipu6-6.5.6-300.fc39.x86_64-0.0-9.20230622git8e41080.fc39.x86_64 from (none)
ipu6-camera-bins-firmware-0.0-8.20230208git276859f.fc39.x86_64 from RPM Fusion
And I rebooted twice :)
Can you help ?
Best Regards,
I executed those commands:
sudo rm -fr /usr/lib/firmware/intel/ipu6*
sudo apt install linux-firmware --reinstall
sudo apt install linux-modules-ipu6-generic-hwe-22.04 linux-modules-ivsc-generic-hwe-22.04 --reinstall
sudo apt install v4l2loopback-dkms v4l2-relayd v4l-utils --reinstall
sudo add-apt-repository ppa:oem-solutions-group/intel-ipu6
sudo apt install libcamhal0 --reinstall
sudo add-apt-repository -r ppa:oem-solutions-group/intel-ipu6
The cam is detected but the canvas is black as with @fvbock. Could anyone offer some help?
My kernel is 6.5.4-76060504-generic
and I'm on Pop!_OS 22.04 LTS
. When executing sudo dmesg -w | grep ipu
and then gst-launch-1.0 v4l2src ! glimagesink
, it does not show any logs. I have rebooted multiple times but that didn't work either.
@do-nat
Have you tried restarting v4l2-relayd?
systemctl restart v4l2-relayd.service
What does
systemctl status v4l2-relayd.service
say?
Does your /etc/v4l2-relayd have the correct content?
VIDEOSRC=icamerasrc buffer-count=7
FORMAT=NV12
WIDTH=1280
HEIGHT=720
FRAMERATE=30/1
CARD_LABEL=Intel MIPI Camera
I have the same symptoms as @do-nat (camera detected, black window, no errors from gst-launch). Unlike do-nat I'm on Ubuntu 23.10 and had followed the steps from @omriasta's last comment.
Restarting v4l2-relayd has no impact. This is the output from status:
Loaded: loaded (/lib/systemd/system/v4l2-relayd.service; enabled; preset: enabled)
Active: active (running) since Mon 2023-10-16 19:22:04 BST; 27s ago
Process: 5773 ExecCondition=/usr/bin/test -n ${VIDEOSRC} (code=exited, status=0/SUCCESS)
Process: 5776 ExecCondition=/usr/bin/test -n $FORMAT (code=exited, status=0/SUCCESS)
Process: 5777 ExecCondition=/usr/bin/test -n $WIDTH (code=exited, status=0/SUCCESS)
Process: 5778 ExecCondition=/usr/bin/test -n $HEIGHT (code=exited, status=0/SUCCESS)
Process: 5779 ExecCondition=/usr/bin/test -n $FRAMERATE (code=exited, status=0/SUCCESS)
Process: 5780 ExecCondition=/usr/bin/test -n ${CARD_LABEL} (code=exited, status=0/SUCCESS)
Main PID: 5781 (v4l2-relayd)
Tasks: 5 (limit: 18579)
Memory: 9.0M
CPU: 126ms
CGroup: /system.slice/v4l2-relayd.service
└─5781 /usr/bin/v4l2-relayd -i "icamerasrc buffer-count=7" -o "appsrc name=appsrc caps=video/x-raw,format=NV12,width=1280,height=720,framerate=30/1 ! videoconvert ! v4l2s>
Oct 16 19:22:04 sglaptop systemd[1]: Starting v4l2-relayd.service - v4l2-relay daemon service...
Oct 16 19:22:04 sglaptop systemd[1]: Started v4l2-relayd.service - v4l2-relay daemon service.
Oct 16 19:22:07 sglaptop v4l2-relayd[5781]: g_param_spec_enum: assertion 'g_enum_get_value (enum_class, default_value) != NULL' failed
Oct 16 19:22:07 sglaptop v4l2-relayd[5781]: validate_pspec_to_install: assertion 'G_IS_PARAM_SPEC (pspec)' failed
Oct 16 19:22:07 sglaptop v4l2-relayd[5781]: g_param_spec_ref_sink: assertion 'G_IS_PARAM_SPEC (pspec)' failed
Oct 16 19:22:07 sglaptop v4l2-relayd[5781]: g_param_spec_unref: assertion 'G_IS_PARAM_SPEC (pspec)' failed
My /etc/v4l2-relayd
is identical to the one in @dennis-pries's comment.
Running on a XPS 9320.
@seangarner what application are you using to view the webcam? I am also on 23.10 now. I do get the black screen as well but eventually the camera works. Here is what I do: launch Google meet or teams meeting in chrome or Firefox. Once it's launched I see the camera light turn on. After that I restart the v4l2-relayd several times (wait 10-20 seconds between restarts to let it do its thing). Usually that will work but sometimes it does not and then I end the meeting and relaunch it. It just takes a few tries but always works at the end. I wish I had more technical details of why it works when it does but not knowledgeable enough to dig that deep.
@omriasta what laptop and OS are you on? Sounds like what I'm seeing on X1 Carbon Gen 11 with ov2740 sensor (see https://github.com/intel/ipu6-drivers/issues/187). Had those exact symptoms on Ubuntu, Fedora and Manjaro
@lukemarsden x1 carbon gen 10 Ubuntu 23.10, was on 23.04 before. Same symptoms on both os's.
@omriasta I've tried webcamtests.com in firefox, which takes about 90 seconds to run all tests. Also zoom in settings, and slack. No light coming on for me though.
Thank you to everyone who has reported the issues with the rpmfusion IPU6 packages with kernel >= 6.5 on Dell laptop models.
This is caused by a new mainline ov0a10 sensor driver which takes precedence over the akmod ov0a10 driver but lacks VSC integration.
This can be worked around by running the following command:
sudo rm /lib/modules/$(uname -r)/kernel/drivers/media/i2c/ov01a10.ko.xz
sudo depmod -a
sudo rmmod ov01a10
sudo modprobe ov01a10
Or reboot instead of the rmmod + modprobe. After this your camera will hopefully work again.
I have submitted a pull-request to disable the mainline kernel's non working ov01a10 driver, so after the next Fedora kernel update this workaround should no longer be necessary.
@superm1 Please come back to Dell. I'll start a crowdfund page if you would consider it ;). (More seriously, I hope you're enjoying your new job!).
hi @jwrdegoede
sudo rm /lib/modules/$(uname -r)/kernel/drivers/media/i2c/ov01a10.ko.xz sudo depmod -a sudo rmmod ov01a10 sudo modprobe ov01a10
Or reboot instead of the rmmod + modprobe. After this your camera will hopefully work again.
I've done this but the problem is the same, blank screen on camera:
[qua out 25 09:29:01 2023] intel-ipu6-isys intel-ipu6-isys0: stream on ov02c10 21-0036
[qua out 25 09:31:37 2023] iwlwifi 0000:00:14.3: Unhandled alg: 0x703
$ ls -la /lib/modules/$(uname -r)/kernel/drivers/media/i2c/ov01a10.ko.xz
ls: cannot access '/lib/modules/6.5.6-300.fc39.x86_64/kernel/drivers/media/i2c/ov01a10.ko.xz': No such file or directory
$ uptime
09:32:05 up 17 min, 4 users, load average: 3.51, 2.44, 1.57
Thanks,
not working for me either on Dell XPS Plus 9320 1360P ; @jwrdegoede solution doesn't make any difference. I hope I didn't break anything further.
# uname -a
Linux roach 6.1.0-1024-oem #24-Ubuntu SMP PREEMPT_DYNAMIC Wed Oct 4 10:18:09 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
# \cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.3 LTS"
I've done this but the problem is the same, blank screen on camera:
[qua out 25 09:29:01 2023] intel-ipu6-isys intel-ipu6-isys0: stream on ov02c10 21-0036 [qua out 25 09:31:37 2023] iwlwifi 0000:00:14.3: Unhandled alg: 0x703 $ ls -la /lib/modules/$(uname -r)/kernel/drivers/media/i2c/ov01a10.ko.xz ls: cannot access '/lib/modules/6.5.6-300.fc39.x86_64/kernel/drivers/media/i2c/ov01a10.ko.xz': No such file or directory $ uptime 09:32:05 up 17 min, 4 users, load average: 3.51, 2.44, 1.57
Ok so your model is using an ov02c10 sensor and on the kernel side everything seems to be properly recognized for you to get to the intel-ipu6-isys intel-ipu6-isys0: stream on ov02c10 21-0036
point.
I assume that all your packages are fully up to date ?
Let me update my own Dell with IPU6 (Dell Latitude 9420 (Tiger Lake, ov01a1s)) to F39 and see if I can reproduce the problem with F39...
Can you please move these specific problems into separate issue?
@fapgomes I've updated the 2 laptops with IPU6 based camera which I have to F39 but I still cannot reproduce your issue I'm afraid.
Does your Dell 9440 have the electronic camera shutter? And if yes do you hear it "click" open when starting a camera app? If you have the electronic camera shutter try using the Fn key to open/close the shutter.
If that does not help, is there anything useful shown in journalctl
output after trying to use the camera?
@jwrdegoede Dell XPS 13 Plus 9320 running F38 here, after doing your steps above I get a black screen instead of an error now. journalctl
captures just one log line when I activate the camera on the gUM test page.
Oct 25 15:03:35 localhost-live.localdomain v4l2-relayd[1448]: gst_element_set_state: assertion 'GST_IS_ELEMENT (element)' failed
Happy to provide any other information that might be helpful, and thanks for your persistence helping out with this so far!
Relevant log lines if I start Cheese
Oct 25 15:09:00 localhost-live.localdomain pipewire[2574]: spa.v4l2: '/dev/video0' can't allocate enough buffers (2 < 16)
Oct 25 15:09:00 localhost-live.localdomain pipewire[2574]: pw.port: 0x5638290f1b00: negotiate buffers on node: -95 (Operation not supported)
Oct 25 15:09:00 localhost-live.localdomain pipewire[2574]: pw.port: 0x5638290f1b00: state ready -> error (can't negotiate buffers on port)
Oct 25 15:09:00 localhost-live.localdomain pipewire[2574]: pw.link: (42.0.0 -> 76.0.0) allocating -> error (can't negotiate buffers on port) (error-ready)
Oct 25 15:09:00 localhost-live.localdomain pipewire[2574]: pw.core: 0x563829019b00: error -32 for resource 33: can't negotiate buffers on port
Oct 25 15:09:00 localhost-live.localdomain pipewire[2574]: mod.client-node: 0x56382934e110: error seq:217 -32 (can't negotiate buffers on port)
Oct 25 15:09:00 localhost-live.localdomain pipewire[2574]: pw.core: 0x563829019b00: error -32 for resource 33: can't negotiate buffers on port
Oct 25 15:09:00 localhost-live.localdomain pipewire[2574]: mod.client-node: 0x56382934e110: error seq:217 -32 (can't negotiate buffers on port)
Oct 25 15:09:00 localhost-live.localdomain pipewire[2574]: spa.v4l2: '/dev/video0' can't allocate enough buffers (2 < 16)
Oct 25 15:09:00 localhost-live.localdomain pipewire[2574]: pw.port: 0x5638290f1b00: negotiate buffers on node: -95 (Operation not supported)
Oct 25 15:09:00 localhost-live.localdomain pipewire[2574]: pw.port: 0x5638290f1b00: state ready -> error (can't negotiate buffers on port)
Oct 25 15:09:00 localhost-live.localdomain pipewire[2574]: pw.link: (42.0.0 -> 77.0.0) allocating -> error (can't negotiate buffers on port) (error-ready)
Oct 25 15:09:00 localhost-live.localdomain pipewire[2574]: pw.core: 0x563829019b00: error -32 for resource 33: can't negotiate buffers on port
Oct 25 15:09:00 localhost-live.localdomain pipewire[2574]: mod.client-node: 0x56382930ce10: error seq:264 -32 (can't negotiate buffers on port)
Oct 25 15:09:00 localhost-live.localdomain pipewire[2574]: pw.core: 0x563829019b00: error -32 for resource 33: can't negotiate buffers on port
Oct 25 15:09:00 localhost-live.localdomain pipewire[2574]: mod.client-node: 0x56382930ce10: error seq:264 -32 (can't negotiate buffers on port)
Oct 25 15:09:00 localhost-live.localdomain cheese[5786]: stream error: can't negotiate buffers on port: ../src/gst/gstpipewiresrc.c(685): on_state_changed (): /GstCameraBin:camerabin/GstWrapperCameraBinSrc:camera_source/GstBin:bin36/GstPipeWireSrc:pipewiresrc1
More system details
[jonathan@localhost-live ~]$ v4l2-ctl --list-devices
ipu6 (PCI:pci:pci0000:00):
/dev/video7
ipu6 (pci:pci0000:00):
/dev/media0
Intel MIPI Camera (platform:v4l2loopback-000):
/dev/video0
[jonathan@localhost-live ~]$ uname -a
Linux localhost-live.localdomain 6.5.8-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Oct 20 15:53:48 UTC 2023 x86_64 GNU/Linux
@kudos 2 things to try:
Sometimes starting the gstreamer pipeline in v4l2-relayd fails and then v4l2-relayd hangs, please try:
systemctl stop v4l2-relayd.service
systemctl start v4l2-relayd.service
and see if that helps.
Otherwise try directly using the camera without v4l2-relayd:
systemctl stop v4l2-relayd.service
gst-launch-1.0 icamerasrc buffer-count=7 ! video/x-raw,format=NV12,width=1280,height=720 ! videoconvert ! xvimagesink
and see if that at least works.
@paulmenzel
Can you please move these specific problems into separate issue?
You are not wrong, but it seems it is too late for this. It might be best to change the title of this issue to "IPU6 distro packaging issues" and start a new issue about upstreaming ?
@jwrdegoede Stopping and starting v4l2-relayd didn't do anything, but invoking gstreamer directly gave a potentially useful output.
[jonathan@localhost-live ~]$ sudo systemctl stop v4l2-relayd.service
[jonathan@localhost-live ~]$ gst-launch-1.0 icamerasrc buffer-count=7 ! video/x-raw,format=NV12,width=1280,height=720 ! videoconvert ! xvimagesink
WARNING: erroneous pipeline: no element "icamerasrc"
WARNING: erroneous pipeline: no element "icamerasrc"
Hmm, so 2 more questions:
ls -l /run/libcamhal.so
? This should show it is a symlink to /usr/lib64/ipu6ep/libcamhal.so
ldd -r /usr/lib64/gstreamer-1.0/libgsticamerasrc.so
?Note if the output of 1. is not as expected please try manually creating the symlink and see if the gst-launch-1.0 icamerasrc ...
does work after creating the symlink. If things still fail please run the command from 2. and let me know the output.
[jonathan@localhost-live ~]$ ls -l /run/libcamhal.so
lrwxrwxrwx. 1 root root 30 Oct 25 14:23 /run/libcamhal.so -> /usr/lib64/ipu6ep/libcamhal.so
[jonathan@localhost-live ~]$ ldd -r /usr/lib64/gstreamer-1.0/libgsticamerasrc.so
linux-vdso.so.1 (0x00007ffe837f8000)
libgstallocators-1.0.so.0 => /lib64/libgstallocators-1.0.so.0 (0x00007fa32290c000)
libgstvideo-1.0.so.0 => /lib64/libgstvideo-1.0.so.0 (0x00007fa322840000)
libgsticamerainterface-1.0.so.1 => /lib64/libgsticamerainterface-1.0.so.1 (0x00007fa32283b000)
libgstbase-1.0.so.0 => /lib64/libgstbase-1.0.so.0 (0x00007fa3227b8000)
libgstcontroller-1.0.so.0 => /lib64/libgstcontroller-1.0.so.0 (0x00007fa3227a5000)
libgstreamer-1.0.so.0 => /lib64/libgstreamer-1.0.so.0 (0x00007fa322655000)
libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007fa3225f3000)
libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007fa3224aa000)
libdrm_intel.so.1 => /lib64/libdrm_intel.so.1 (0x00007fa322485000)
libdrm.so.2 => /lib64/libdrm.so.2 (0x00007fa32246e000)
libcamhal.so => /lib64/libcamhal.so (0x00007fa322000000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fa321c00000)
libm.so.6 => /lib64/libm.so.6 (0x00007fa321f1f000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fa322448000)
libc.so.6 => /lib64/libc.so.6 (0x00007fa321a22000)
liborc-0.4.so.0 => /lib64/liborc-0.4.so.0 (0x00007fa3223b2000)
libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00007fa3223ab000)
libunwind.so.8 => /lib64/libunwind.so.8 (0x00007fa32238f000)
libdw.so.1 => /lib64/libdw.so.1 (0x00007fa321e87000)
libffi.so.8 => /lib64/libffi.so.8 (0x00007fa321e7b000)
libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007fa321988000)
libpciaccess.so.0 => /lib64/libpciaccess.so.0 (0x00007fa321e6f000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fa32195d000)
libia_cca.so => /usr/lib64/ipu6ep/libia_cca.so (0x00007fa321941000)
libia_log.so => /usr/lib64/ipu6ep/libia_log.so (0x00007fa321e69000)
libgcss.so.0 => /usr/lib64/ipu6ep/libgcss.so.0 (0x00007fa3218c6000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa32295f000)
libelf.so.1 => /lib64/libelf.so.1 (0x00007fa3218a9000)
libz.so.1 => /lib64/libz.so.1 (0x00007fa32188f000)
libzstd.so.1 => /lib64/libzstd.so.1 (0x00007fa3217d3000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fa3217a0000)
libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fa32178c000)
libia_bcomp.so => /usr/lib64/ipu6ep/libia_bcomp.so (0x00007fa321e61000)
libia_lard.so => /usr/lib64/ipu6ep/libia_lard.so (0x00007fa321e59000)
libia_emd_decoder.so => /usr/lib64/ipu6ep/libia_emd_decoder.so (0x00007fa321786000)
libia_ccat.so => /usr/lib64/ipu6ep/libia_ccat.so (0x00007fa32174b000)
libia_isp_bxt.so => /usr/lib64/ipu6ep/libia_isp_bxt.so (0x00007fa321715000)
libia_aiq.so => /usr/lib64/ipu6ep/libia_aiq.so (0x00007fa32164f000)
libia_dvs.so => /usr/lib64/ipu6ep/libia_dvs.so (0x00007fa32162d000)
libia_ltm.so => /usr/lib64/ipu6ep/libia_ltm.so (0x00007fa3215fa000)
libia_cmc_parser.so => /usr/lib64/ipu6ep/libia_cmc_parser.so (0x00007fa3215e1000)
libia_mkn.so => /usr/lib64/ipu6ep/libia_mkn.so (0x00007fa3215da000)
libia_exc.so => /usr/lib64/ipu6ep/libia_exc.so (0x00007fa3215d3000)
libia_coordinate.so => /usr/lib64/ipu6ep/libia_coordinate.so (0x00007fa3215cd000)
libbroxton_ia_pal.so => /usr/lib64/ipu6ep/libbroxton_ia_pal.so (0x00007fa321000000)
libia_aiqb_parser.so => /usr/lib64/ipu6ep/libia_aiqb_parser.so (0x00007fa3215c2000)
libia_nvm.so => /usr/lib64/ipu6ep/libia_nvm.so (0x00007fa3215bb000)
Ok, so that looks good. what happens if you run rm ~/.cache/gstreamer-1.0/registry.x86_64.bin
and then retry the gst-launch command ?
Ok, gst-launch-1.0 icamerasrc buffer-count=7 ! video/x-raw,format=NV12,width=1280,height=720 ! videoconvert ! xvimagesink
now pops up a window with the webcam working! However, even after systemctl start v4l2-relayd.service
Cheese still says There was an error playing video from the webcam
and the gUM test page is still a black box with the same error as before.
Ok, so we have a working camera now, that is good :)
For the gUM test page please try sudo rm /root/.cache/gstreamer-1.0/registry.x86_64.bin
and then restart v4l2-relayd.service
again. After this I expect the gUM page (and thus video conferencing) to also work.
As for cheese, cheese does not like the v4l2 compatibility provided by v4l2-relayd. I still need to debug this one of these days, but for now cheese is not a good way to test ipu6 cameras because of this. My advice for testing is to use the gUM page.
Yep, that fixed it in Firefox. Unfortunately, we can add Zoom to the list of applications that aren't happy with the v4l2 compatibility :(
@jwrdegoede
Does your Dell 9440 have the electronic camera shutter?
Yes.
And if yes do you hear it "click" open when starting a camera app? If you have the electronic camera shutter try using the Fn key to open/close the shutter.
Yes, when I click on F9 (electronic camera shutter) I hear a click and the "red item" on front of the camera disapear (if I click again, it appears again and I hear again the click).
If that does not help, is there anything useful shown in
journalctl
output after trying to use the camera?
I've this on start:
out 25 18:27:06 pluto v4l2-relayd[1698]: Registering meta implementation 'GstCamerasrcMeta' without init function
out 25 18:27:06 pluto kernel: intel-ipu6-isys intel-ipu6-isys0: no pipe or streaming, adding to incoming
out 25 18:27:06 pluto kernel: intel-ipu6-isys intel-ipu6-isys0: no pipe or streaming, adding to incoming
out 25 18:27:06 pluto kernel: intel-ipu6-isys intel-ipu6-isys0: no pipe or streaming, adding to incoming
out 25 18:27:06 pluto kernel: intel-ipu6-isys intel-ipu6-isys0: stream on ov02c10 19-0036
out 25 18:27:06 pluto kernel: vsc_csi spi-INTC1009:00-92335fcf-3203-4472-af93-7b4453ac29da: privacy on, command id = 0
out 25 18:27:08 pluto sh[1698]: [10-25 18:27:06.669] CamHAL[INF] aiqb file name OV02C10_1BG203N3_ADL.aiqb
out 25 18:27:08 pluto sh[1698]: [10-25 18:27:06.670] CamHAL[INF] aiqb file name OV02C10_1BG203N3_ADL.aiqb
out 25 18:27:08 pluto sh[1698]: [10-25 18:27:06.670] CamHAL[INF] aiqb file name OV02C10_1SG204N3_ADL.aiqb
out 25 18:27:08 pluto sh[1698]: [10-25 18:27:06.671] CamHAL[INF] aiqb file name OV02C10_1SG204N3_ADL.aiqb
out 25 18:27:08 pluto sh[1698]: [10-25 18:27:06.671] CamHAL[INF] aiqb file name OV02C10_CIFME14_ADL.aiqb
out 25 18:27:08 pluto sh[1698]: [10-25 18:27:06.672] CamHAL[INF] aiqb file name OV02C10_CIFME14_ADL.aiqb
out 25 18:27:08 pluto sh[1698]: [10-25 18:27:07.96] CamHAL[INF] threadLoop: mCameraStreams[0] == 0x7ffa800274f0
out 25 18:27:08 pluto sh[1698]: [10-25 18:27:07.96] CamHAL[INF] threadLoop: getPrivacyBuffer returned nullptr
out 25 18:27:08 pluto sh[1698]: [10-25 18:27:07.163] CamHAL[INF] threadLoop: mCameraStreams[0] == 0x7ffa800274f0
out 25 18:27:08 pluto sh[1698]: [10-25 18:27:07.163] CamHAL[INF] threadLoop: getPrivacyBuffer returned nullptr
out 25 18:27:08 pluto sh[1698]: [10-25 18:27:07.197] CamHAL[ERR] Poll: Device node fd 22 poll timeout.
out 25 18:27:08 pluto sh[1698]: [10-25 18:27:07.230] CamHAL[INF] threadLoop: mCameraStreams[0] == 0x7ffa800274f0
out 25 18:27:08 pluto sh[1698]: [10-25 18:27:07.230] CamHAL[INF] threadLoop: getPrivacyBuffer returned nullptr
out 25 18:27:08 pluto sh[1698]: [10-25 18:27:07.298] CamHAL[ERR] Poll: Device node fd 22 poll timeout.
and the errors are the same when I try to use the camera (without the privacy mode off), adding this errors:
out 25 18:30:56 pluto kernel: vsc_csi spi-INTC1009:00-92335fcf-3203-4472-af93-7b4453ac29da: privacy off
out 25 18:31:01 pluto sh[1698]: [10-25 18:30:56.891] CamHAL[ERR] Poll: Device node fd 22 poll timeout.
out 25 18:31:01 pluto sh[1698]: [10-25 18:30:56.938] CamHAL[INF] threadLoop: mCameraStreams[0] == 0x7ffa800274f0
out 25 18:31:01 pluto sh[1698]: [10-25 18:30:56.938] CamHAL[INF] threadLoop: getPrivacyBuffer returned nullptr
out 25 18:31:01 pluto sh[1698]: [10-25 18:30:56.991] CamHAL[ERR] Poll: Device node fd 22 poll timeout.
out 25 18:31:01 pluto sh[1698]: [10-25 18:30:57.91] CamHAL[ERR] Poll: Device node fd 22 poll timeout.
out 25 18:31:01 pluto sh[1698]: [10-25 18:30:57.104] CamHAL[WAR] <id0>@waitFrame, time out happens, wait recovery
out 25 18:31:01 pluto sh[1698]: [10-25 18:30:57.192] CamHAL[ERR] Poll: Device node fd 22 poll timeout.
out 25 18:31:01 pluto sh[1698]: [10-25 18:30:57.292] CamHAL[ERR] Poll: Device node fd 22 poll timeout.
out 25 18:31:01 pluto sh[1698]: [10-25 18:30:57.325] CamHAL[ERR] Poll: Device node fd 24 poll timeout.
out 25 18:31:01 pluto sh[1698]: [10-25 18:30:57.392] CamHAL[ERR] Poll: Device node fd 22 poll timeout.
out 25 18:31:01 pluto sh[1698]: [10-25 18:30:57.492] CamHAL[ERR] Poll: Device node fd 22 poll timeout.
out 25 18:31:01 pluto sh[1698]: [10-25 18:30:57.592] CamHAL[ERR] Poll: Device node fd 22 poll timeout.
out 25 18:31:01 pluto sh[1698]: [10-25 18:30:57.592] CamHAL[INF] Sof poll time out.
out 25 18:31:01 pluto sh[1698]: [10-25 18:30:57.692] CamHAL[ERR] Poll: Device node fd 22 poll timeout.
out 25 18:31:01 pluto sh[1698]: [10-25 18:30:57.793] CamHAL[ERR] Poll: Device node fd 22 poll timeout.
out 25 18:31:01 pluto sh[1698]: [10-25 18:30:57.893] CamHAL[ERR] Poll: Device node fd 22 poll timeout.
out 25 18:31:01 pluto sh[1698]: [10-25 18:30:57.993] CamHAL[ERR] Poll: Device node fd 22 poll timeout.
out 25 18:31:01 pluto sh[1698]: [10-25 18:30:58.93] CamHAL[ERR] Poll: Device node fd 22 poll timeout.
out 25 18:31:01 pluto sh[1698]: [10-25 18:30:58.193] CamHAL[ERR] Poll: Device node fd 22 poll timeout.
out 25 18:31:01 pluto sh[1698]: [10-25 18:30:58.293] CamHAL[ERR] Poll: Device node fd 22 poll timeout.
out 25 18:31:01 pluto sh[1698]: [10-25 18:30:58.327] CamHAL[ERR] Poll: Device node fd 24 poll timeout.
out 25 18:31:01 pluto sh[1698]: [10-25 18:30:58.394] CamHAL[ERR] Poll: Device node fd 22 poll timeout.
out 25 18:31:01 pluto sh[1698]: [10-25 18:30:58.494] CamHAL[ERR] Poll: Device node fd 22 poll timeout.
out 25 18:31:01 pluto sh[1698]: [10-25 18:30:58.594] CamHAL[ERR] Poll: Device node fd 22 poll timeout.
out 25 18:31:01 pluto sh[1698]: [10-25 18:30:58.694] CamHAL[ERR] Poll: Device node fd 22 poll timeout.
out 25 18:31:01 pluto sh[1698]: [10-25 18:30:58.773] CamHAL[WAR] wait event time out, 1 requests processing, 5 requests in HAL
Thanks
@fapgomes, so your camera shutter is working properly and it seems that the issue is that the sensor never starts streaming data.
I'm afraid I don't have any ideas how to solve or further debug this.
We have seen similar issues on some Lenovo laptops where the stream only starts some of the time (only 1 out of 10 attempts). Those are also unsolved and those may not even be related to your issue.
Dell XPS 9320 Fedora 38 with kernel 6.5.8-200.fc38.x86_64
Chees on device ipu6 fails with 'Device wants 2:0:0:0 colorimetry'. Cheese on device Intel MIPI Camera is only black.
$ cheese
(cheese:2618): Gdk-CRITICAL **: 00:59:31.588: gdk_atom_intern: assertion 'atom_name != NULL' failed
(cheese:2618): Gdk-CRITICAL **: 00:59:31.588: gdk_atom_intern: assertion 'atom_name != NULL' failed
(cheese:2618): cheese-WARNING **: 00:59:31.851: Device '/dev/video7' does not support 2:0:0:0 colorimetry: ../sys/v4l2/gstv4l2object.c(4221): gst_v4l2_object_set_format_full (): /GstCameraBin:camerabin/GstWrapperCameraBinSrc:camera_source/GstBin:bin36/GstV4l2Src:v4l2src1:
Device wants 2:0:0:0 colorimetry
Installed akmod-intel-ipu6 with dependencies :
sudo dnf install --enablerepo=rpmfusion-nonfree --enablerepo=rpmfusion-nonfree-updates --enablerepo=rpmfusion-free --enablerepo=rpmfusion-free-updates akmod-intel-ipu6
Devices:
$ v4l2-ctl --list-devices
ipu6 (PCI:pci:pci0000:00):
/dev/video7
ipu6 (pci:pci0000:00):
/dev/media0
Intel MIPI Camera (platform:v4l2loopback-000):
/dev/video0
I have tried most of the tips mentioned here and other sources withiut luck. Including the one with removing a driver: https://github.com/intel/ipu6-drivers/issues/22#issuecomment-1777054067
This intel generation and lack of drivers is giving me severe headaches at the moment. Would also be nice to get the i915 SR-VIO drivers merged soon.
Do we have a proposed timeline for getting proper driver support merged to mainline?
@feskehau
Do we have a proposed timeline for getting proper driver support merged to mainline?
The ISYS (input subsystem) driver is on its way to mainline, if all goes well I think it could make it in v6.9 at the earliest. That will give you images, but they will be pretty much unusable. The get a decent quality, the PSYS (processing subsystem) driver is needed too, as well as corresponding code to drive it for libcamera (if you're familiar with GPUs, that would be the Mesa-side of the 3D driver). I wouldn't expect that to be merged in mainline before 2025.
@feskehau
Do we have a proposed timeline for getting proper driver support merged to mainline?
The ISYS (input subsystem) driver is on its way to mainline, if all goes well I think it could make it in v6.9 at the earliest. That will give you images, but they will be pretty much unusable. The get a decent quality, the PSYS (processing subsystem) driver is needed too, as well as corresponding code to drive it for libcamera (if you're familiar with GPUs, that would be the Mesa-side of the 3D driver). I wouldn't expect that to be merged in mainline before 2025.
Thanks for the info: Last i read was this: https://lore.kernel.org/linux-media/ZHPD40NVGgFr3Iek@kekkonen.localdomain/
[user@webcam ~]$ rm ~/.cache/gstreamer-1.0/registry.x86_64.bin
[user@webcam ~]$ sudo systemctl stop v4l2-relayd.service
[user@webcam ~]$ gst-launch-1.0 icamerasrc buffer-count=7 ! video/x-raw,format=NV12,width=1280,height=720 ! videoconvert ! xvimagesink
Setting pipeline to PAUSED ...
ERROR: from element /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0: Could not initialise Xv output
Additional debug info:
../sys/xvimage/xvimagesink.c(1944): gst_xv_image_sink_open (): /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0:
No Xv Port available
ERROR: pipeline doesn't want to preroll.
Failed to set pipeline to PAUSED.
Setting pipeline to NULL ...
Freeing pipeline ...
@feskehau:
Dell XPS 9320 Fedora 38 with kernel 6.5.8-200.fc38.x86_64
Ok, that should work
Cheese on device ipu6 fails with ...
Cheese is known to not work with the v4l2-loopback / v4l-relayd v4l2 compatibility. This is something which I plan to look into at some point, but it is somewhat low priority.
To see if the IPU6 camera stack works, try running from a terminal:
sudo systemctl stop v4l2-relayd.service
gst-launch-1.0 icamerasrc buffer-count=7 ! video/x-raw,format=NV12,width=1280,height=720 ! videoconvert ! xvimagesink
If that works restart v4l2-relayd:
sudo systemctl start v4l2-relayd.service
And then try the v4l2 compatibility with https://mozilla.github.io/webrtc-landing/gum_test.html under firefox, which should also work.
So no cheese, but you should be able to use the camera for video-conferencing in firefox and chrome.
@feskehau
Do we have a proposed timeline for getting proper driver support merged to mainline?
The ISYS (input subsystem) driver is on its way to mainline, if all goes well I think it could make it in v6.9 at the earliest. That will give you images, but they will be pretty much unusable. The get a decent quality, the PSYS (processing subsystem) driver is needed too, as well as corresponding code to drive it for libcamera (if you're familiar with GPUs, that would be the Mesa-side of the 3D driver). I wouldn't expect that to be merged in mainline before 2025.
Thanks for the info: Last i read was this: https://lore.kernel.org/linux-media/ZHPD40NVGgFr3Iek@kekkonen.localdomain/
One of the main rules of software development is that things take more time than planned, regardless of how much time you plan :) I would still say I feel confident that the ISYS driver will make it to mainline at some point.
@feskehau:
Dell XPS 9320 Fedora 38 with kernel 6.5.8-200.fc38.x86_64
Ok, that should work
Correction you need to be on at least 6.5.9 or use the workaround from https://hansdegoede.dreamwidth.org/27737.html
on all three:
[user@webcam-fed yum.repos.d]$ sudo systemctl status v4l2-relayd
× v4l2-relayd.service - v4l2-relay daemon service
Loaded: loaded (/usr/lib/systemd/system/v4l2-relayd.service; enabled; preset: enabled)
Drop-In: /usr/lib/systemd/system/service.d
└─10-timeout-abort.conf
Active: failed (Result: start-limit-hit) since Tue 2023-10-31 13:40:11 CET; 5min ago
Duration: 27ms
Process: 1032 ExecCondition=/usr/bin/test -n ${VIDEOSRC} (code=exited, status=0/SUCCESS)
Process: 1034 ExecCondition=/usr/bin/test -n $FORMAT (code=exited, status=0/SUCCESS)
Process: 1035 ExecCondition=/usr/bin/test -n $WIDTH (code=exited, status=0/SUCCESS)
Process: 1036 ExecCondition=/usr/bin/test -n $HEIGHT (code=exited, status=0/SUCCESS)
Process: 1037 ExecCondition=/usr/bin/test -n $FRAMERATE (code=exited, status=0/SUCCESS)
Process: 1038 ExecCondition=/usr/bin/test -n ${CARD_LABEL} (code=exited, status=0/SUCCESS)
Process: 1039 ExecStart=/bin/sh -c DEVICE=$(grep -l -m1 -E "^${CARD_LABEL}$" /sys/devices/virtual/video4linux/*/name | cut -d/ -f6); exec /usr/bin/v4l2-relayd -i "${VIDEOSRC}" $${SPLASHSRC:+-s "${SPLASHSRC}"} -o "appsrc name=appsrc c>
Main PID: 1039 (code=exited, status=0/SUCCESS)
CPU: 34ms
Oct 31 13:40:11 webcam-fed systemd[1]: v4l2-relayd.service: Scheduled restart job, restart counter is at 5. Oct 31 13:40:11 webcam-fed systemd[1]: Stopped v4l2-relayd.service - v4l2-relay daemon service. Oct 31 13:40:11 webcam-fed systemd[1]: v4l2-relayd.service: Start request repeated too quickly. Oct 31 13:40:11 webcam-fed systemd[1]: v4l2-relayd.service: Failed with result 'start-limit-hit'. Oct 31 13:40:11 webcam-fed systemd[1]: Failed to start v4l2-relayd.service - v4l2-relay daemon service.
- Trying camera with gst-launch without v4l2-relayd crashes with no Vx Port available.
[user@webcam-fed yum.repos.d]$ sudo systemctl stop v4l2-relayd.service [user@webcam-fed yum.repos.d]$ gst-launch-1.0 icamerasrc buffer-count=7 ! video/x-raw,format=NV12,width=1280,height=720 ! videoconvert ! xvimagesink Setting pipeline to PAUSED ... ERROR: from element /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0: Could not initialise Xv output Additional debug info: ../sys/xvimage/xvimagesink.c(1944): gst_xv_image_sink_open (): /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0: No Xv Port available ERROR: pipeline doesn't want to preroll. Failed to set pipeline to PAUSED. Setting pipeline to NULL ... Freeing pipeline ...
Some other info:
[user@webcam-fed yum.repos.d]$ uname -a Linux webcam-fed 6.5.9-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Oct 25 20:40:49 UTC 2023 x86_64 GNU/Linux [user@webcam-fed yum.repos.d]$ lsmod | grep ipu6 intel_ipu6_isys 167936 0 videobuf2_dma_contig 28672 1 intel_ipu6_isys videobuf2_v4l2 40960 1 intel_ipu6_isys videobuf2_common 94208 4 videobuf2_dma_contig,videobuf2_v4l2,intel_ipu6_isys,videobuf2_memops v4l2_fwnode 32768 1 intel_ipu6_isys v4l2_async 28672 2 v4l2_fwnode,intel_ipu6_isys videodev 389120 7 v4l2_async,v4l2_fwnode,videobuf2_v4l2,v4l2loopback,intel_ipu6_isys mc 90112 5 v4l2_async,videodev,videobuf2_v4l2,intel_ipu6_isys,videobuf2_common intel_ipu6_psys 126976 0 intel_ipu6 143360 2 intel_ipu6_isys,intel_ipu6_psys [user@webcam-fed yum.repos.d]$ lspci -v .........
00:06.0 Multimedia controller: Intel Corporation Device a75d
Subsystem: Dell Device 0c10
Physical Slot: 6
Flags: bus master, fast devsel, latency 0, IRQ 40
Memory at f2000000 (64-bit, non-prefetchable) [size=16M]
Capabilities:
[user@webcam-fed yum.repos.d]$ v4l2-ctl --list-devices ipu6 (PCI:pci:pci0000:00): /dev/video7
ipu6 (pci:pci0000:00): /dev/media0
Intel MIPI Camera (platform:v4l2loopback-000): /dev/video0
@feskehau
Trying camera with gst-launch without v4l2-relayd crashes with no Vx Port available.
Hmm, that is a bit weird. Can you try gst-launch again replacing xvimagesink
with ximagesink
:
gst-launch-1.0 icamerasrc buffer-count=7 ! video/x-raw,format=NV12,width=1280,height=720 ! videoconvert ! ximagesink
And see what that does ?
@jwrdegoede I recently upgraded from Fedora 37 to 38. Under Fedora 37, the camera was working well (or at least as well as can be expected) everywhere that I cared about (both Firefox & Chrome, etc). However, since upgrading to Fedora 38 ( 6.5.10-200.fc38.x86_64), neither Firefox nor Chrome detect the camera at all. Its simply not ever listed as an option anywhere (including the mozilla gum test page).
$ v4l2-ctl --list-devices
ipu6 (PCI:pci:pci0000:00):
/dev/video7
ipu6 (pci:pci0000:00):
/dev/media1
Intel MIPI Camera (platform:v4l2loopback-000):
/dev/video2
Logitech Webcam C930e (usb-0000:00:14.0-3.2):
/dev/video0
/dev/video1
/dev/media0
(note, i've also got the Logitech USB webcam which has been my backup solution, since it works fine 100% of the time)
If I run "gst-launch-1.0 icamerasrc buffer-count=7 ! video/x-raw,format=NV12,width=1280,height=720 ! videoconvert ! ximagesink" then the camera does work fine. So this seems like something specific to browsers that changed?
<30 minutes pass...> After reading through most of the old comments in this issue, I discovered that the problem was that v4l2-relayd.service had failed (at boot?). After restarting it manually, the problem is fixed. I checked the logs, and the service was failing to start with the following output: ``` Nov 14 15:11:30 hal-1 systemd[1]: Starting v4l2-relayd.service - v4l2-relay daemon service... Nov 14 15:11:30 hal-1 systemd[1]: Started v4l2-relayd.service - v4l2-relay daemon service. Nov 14 15:11:30 hal-1 sh[1213]: grep: /sys/devices/virtual/video4linux/*/name: No such file or directory Nov 14 15:11:31 hal-1 v4l2-relayd[1211]: g_source_remove: assertion 'tag > 0' failed Nov 14 15:11:31 hal-1 v4l2-relayd[1211]: g_source_remove: assertion 'tag > 0' failed Nov 14 15:11:31 hal-1 v4l2-relayd[1211]: gst_element_set_state: assertion 'GST_IS_ELEMENT (element)' failed Nov 14 15:11:31 hal-1 v4l2-relayd[1211]: gst_object_unref: assertion 'object != NULL' failed Nov 14 15:11:31 hal-1 v4l2-relayd[1211]: gst_element_set_state: assertion 'GST_IS_ELEMENT (element)' failed Nov 14 15:11:31 hal-1 v4l2-relayd[1211]: gst_object_unref: assertion 'object != NULL' failed Nov 14 15:11:31 hal-1 systemd[1]: v4l2-relayd.service: Deactivated successfully. ``` seems like maybe some sort of race condition at boot maybe ?@pinchartl Would it be possible to get “soft ISP” implemented in libcamera as a workaround until the PSYS driver is ready?
I recently discovered that my ThinkPad X1 Carbon needs an out-of-tree driver (this one) for my camera. That seems atypical for Intel hardware, which is typically well supported upstream.
I've tried with both Debian sid's 5.18.0-2-amd64 and Ubuntu jammy's 5.15, but the driver is included in neither distro, probably because it isn't upstream. Since this hardware is considered important for most people who use an Alder Lake laptop, could you consider upstreaming this driver (and any dependent pieces) into the mainline kernel relatively soon, even if only in the staging area?
I did try to build this myself with DKMS, but due to #13 (both the missing header and then the modpost error), it's not possible to do so, so there is presently no way to make this hardware work on Debian.