This bug is to track an issue which I have been discussing with the reporter over email for quite a while now. The reporter's HP Spectre x360 14-eu0xxx has an OVTI08F4/ov08x40 sensor which is directly connected to GPIOs and a I2C bus coming directly from the main Intel SoC/CPU rather then using an IO-expander like the LJCA chip. The sensor presumably is failing to power-on properly, as the first I2C transfer attempted to the sensor fails with EREMOTEIO which typically means the sensor has not been powered on properly. Despite there not being an IO-expander the Intel IPU INT3472 ACPI sensor-power device driver logs the following: [ 11.594911] int3472-discrete INT3472:01: GPIO type 0x12 unknown; the sensor may not work Where type 0x12 is "handshake" which normally is associated with the new Lattice MIPI aggregator IO-expander / MIPI chip which this laptop appears to not use. It is unclear how to handle this pin. I have provided a test kernel to the reporter which maps this to "reset" but that does not help. Generally speaking the mainline ov08x40 driver lacks code to control the clk and GPIOs which is necessary on Intel IPU6 designs. I have posted a series to add support for these here: https://lore.kernel.org/linux-media/20241219134940.15472-1-hdegoede@redhat.com/ But testing has shown that this is not enough to get things to work. There now also is another reporter with a similar HP laptop which appears to have the same sensor setup and is showing the same problem: https://lore.kernel.org/linux-media/1594170563.10937137.1728935697496.JavaMail.zimbra@chorus.net/ Reproducible: Always
Created attachment 2063303 [details] HP Spectre 16 dmesg with kernel arg intel_skl_int3472_discrete.dyn.dbg Duane Kaufman HP Spectre 16 dmesg with kernel arg intel_skl_int3472_discrete.dyn.dbg
(In reply to Duane Kaufman from comment #1) > Created attachment 2063303 [details] > HP Spectre 16 dmesg with kernel arg intel_skl_int3472_discrete.dyn.dbg > > Duane Kaufman > > HP Spectre 16 dmesg with kernel arg intel_skl_int3472_discrete.dyn.dbg Thank you, So the interesting new log lines here are: [ 4.907022] int3472-discrete INT3472:01: Sensor module id: 'CJFME62' [ 4.908016] int3472-discrete INT3472:01: unknown \_SB.GPI0 pin 65 active-high [ 4.908019] int3472-discrete INT3472:01: GPIO type 0x12 unknown; the sensor may not work [ 4.908099] int3472-discrete INT3472:01: privacy-led \_SB.GPI0 pin number mismatch _DSM 11 resource 107 [ 4.908100] int3472-discrete INT3472:01: privacy-led \_SB.GPI0 pin 107 active-high [ 4.912108] int3472-discrete INT3472:02: Sensor module id: 'CJFME62' [ 4.916184] int3472-discrete INT3472:02: reset \_SB.GPI0 pin number mismatch _DSM 49 resource 209 [ 4.920658] int3472-discrete INT3472:02: reset \_SB.GPI0 pin 209 active-low These show that there are 2 INT3472 power management devices. Likely one per sensor, I expect there will be both a normal camera sensor and an infrared sensor. Still this does not explain why we cannot get the ov08x40 sensor powered up since there are no unhandled GPIO entries other then the "GPIO type 0x12 unknown" which I already tried mapping to "reset" and that did not help. So the next step would be to write a dummy ov08x40 driver which at least enables the clks and then to manually try and see if we can talk to the chip using i2cdetect from userspace after driving all 3 GPIOs (GPI0 pin 65 107 and 209) high using gpioset from userspace. I'm going to turn off my computer real soon and then I'll be off from work for 2 weeks, returning on January 6th. So investigating this further will have to wait till January. In the mean time it would be useful to collect some info for January. Please install the gpiodetect and i2cdetect utilities and run: ls -l /sys/bus/i2c/devices on the "HP Spectre x360 14-eu0xxx" from the other reporter this outputs these lines (amongst others): lrwxrwxrwx 1 root root 0 Oct 5 23:42 i2c-OVTI00AB:00 -> ../../../devices/pci0000:00/0000:00:15.3/i2c_designware.2/i2c-2/i2c-OVTI00AB:00 lrwxrwxrwx 1 root root 0 Oct 5 23:40 i2c-OVTI08F4:00 -> ../../../devices/pci0000:00/0000:00:19.0/i2c_designware.3/i2c-3/i2c-OVTI08F4:00 with the interesting thing being the /i2c-2/ and /i2c-3/ part of the paths, this shows that the OVTI08F4 sensor which is the normal camera sensor is on i2c bus 3. Assuming it is on i2c-bus 3 for you to, please run: i2cdetect -y -r 3 and post the output. I would expect this to show one UU entry which means that that address is claimed / in use and therefor probing is skipped. Note this should run pretty quickly, if it is slow then the i2c-bus has issues (likely due to the sensor not being powered on). It would also be interesting to remove the sensor doing: "sudo rmmod ov08x40" and then do the i2cdetect again. Now it will likely detect nothing. Also please run "sudo gpiodetect" and provide the output of that command too. If gpiodetect shows only 1 chip then we can be sure that that is GPI0 in ACPI and you could try manually setting the GPIOs high after doing the "sudo rmmod ov08x40" by running: gpioset -c gpiochip0 65=1 107=1 209=1 gpioset will keep running to keep the GPIOs claimed, you can do Ctrl+C to cancel it and then run: i2cdetect -y -r 3 again and see if an i2c-device shows up. Note this might not work for 2 possible reasons: 1. Without a dummy driver the ACPI call to enable the clk to the sensor will not be made 2. So far we have failed to power-up the sensor and we have effectively already tried the GPIOs so maybe something extra is needed and we just don't know what
Created attachment 2063345 [details] ov2740 dummy driver If you want to pursue this further yourself, here is a dummy driver which just enables the clk for the ov2740, to adjust this for the ov08x40 all you need to do really is change the ACPI HardwareID from INT3474 to OVTI08F4. I'll also attach a Makefile to build this out of tree.
Created attachment 2063346 [details] Makefile for ov2740dummy driver
One very important thing which I forgot to mention poking GPIOs manually might be dangerous / could in some cases damage your hardware! Which is why I suggested to only do that if "sudo gpiodetect" shows only 1 GPIO chip so that we are sure we are only poking camera related GPIOs.
Ugh, I just learned that my previous attempt to fix this on a "HP Spectre x360 14-eu0xxx" has a bug in one of my patches adding support to the driver to set the GPIO and clks on ACPI platforms, see: https://lore.kernel.org/linux-media/e3573352-f73e-43f5-8e21-6c313dc54057@redhat.com/ That might very well explain why things do not work. So poking GPIOs manually and running i2cdetect is probably not really necessary. Instead what is likely necessary is building a kernel with the patches from this series added: https://lore.kernel.org/linux-media/20241219134940.15472-1-hdegoede@redhat.com/ with the bug in that series which I linked to above fixed. *and* with this patch added as well: https://github.com/jwrdegoede/linux-sunxi/commit/c7803b1a32dab79f8a516e8aa9c08fb4ba74354d
Created attachment 2074443 [details] acpidump from HP Spectre x360 14-eu0xxx
Hello, sorry for the delay, I have a "HP Spectre x360 14-eu0xxx" with Fedora and Debian testing (kernel 6.13.5) The results are the same on Fedora and Debian, just on debian the i2c buses are 3 and 4, because Debian detects i2c-0 with the SMBus I801 adapter: /sys/bus/i2c/devices/i2c-3/i2c-TXNW3643:00 is a led flash for the IR camera (lm3643 with linux drivers to adapt) /sys/bus/i2c/devices/i2c-3/i2c-OVTI00AB:00 is the IR camera (og0va1b with no linux driver) /sys/bus/i2c/devices/i2c-4/i2c-OVTI08F4:00 is the camera and photo (ov08x40) I find it strange that the OVTI08F4 camera is seen as a led /sys/class/leds/OVTI08F4_00::privacy_led /sys/devices/pci0000:00/INT3472:01/leds/OVTI08F4_00::privacy_led (On Fedora as on Debian) I recompiled the kernet with the latest patch proposed on INT3472 discrete.c but with a small difference: + case INT3472_GPIO_TYPE_HANDSHAKE: + *func = "handshake"; + *polarity = GPIO_ACTIVE_HIGH; + break; The dmesg traces give: int3472-discrete INT3472:01: Sensor module id: 'YHEC' int3472-discrete INT3472:01: handshake \_SB.GPI0 pin 65 active-high int3472-discrete INT3472:01: privacy-led \_SB.GPI0 pin number mismatch _DSM 11 resource 107 int3472-discrete INT3472:01: privacy-led \_SB.GPI0 pin 107 active-high int3472-discrete INT3472:02: Sensor module id: 'YHEC' int3472-discrete INT3472:02: reset \_SB.GPI0 pin number mismatch _DSM 49 resource 209 int3472-discrete INT3472:02: reset \_SB.GPI0 pin 209 active-low The i2cdetect gives: sudo i2cdetect -y -r 3 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: 60 -- -- 63 -- -- -- -- -- -- -- -- -- -- -- -- -- 70:70 -- -- -- -- -- -- -- sudo i2cdetect -y -r 4 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- Results are the same on fedora with -r 2 and 3 Hope this helps
I have prepared a test-kernel with the following patches: 1. 2 hi566 power-on sequence fixes (not posted upstream yet) 2. ov02c10 support https://lore.kernel.org/linux-media/20250319145927.70534-1-hdegoede@redhat.com/ 3. ov02e10 support https://lore.kernel.org/linux-media/20250325-b4-media-comitters-next-25-03-13-ov02e10-v2-2-4d933ac8cff6@linaro.org/ 4. Lattice / usbio handshake pin support https://lore.kernel.org/platform-driver-x86/20250325161340.342192-1-hdegoede@redhat.com/ This should make the camera on the laptop from this bug work, please give the test kernel a try: https://koji.fedoraproject.org/koji/taskinfo?taskID=130775742 Here are some instructions for directly installing a kernel from koji: https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt
Thank you for your feedback, I tested this kernel on my "HP Spectre x360 14-eu0xxx": BOOT_IMAGE=/boot/vmlinuz-6.14.0-63.ipu6.fc42.x86_64 root=/dev/nvme0n1p8 No logs for int3472-discrete. But the ov098x40 driver does not work: ov08x40 i2c-OVTI08F4:00: supply dovdd not found, using dummy regulator ov08x40 i2c-OVTI08F4:00: supply avdd not found, using dummy regulator ov08x40 i2c-OVTI08F4:00: error reading chip-id register: -121 ov08x40 i2c-OVTI08F4:00: probe with driver ov08x40 failed with error -121
One small step... I managed to get a video with sudo qcam -s "width=1900,height=1200" This video is not stable. To do this, I compiled kernel 6.15-rc1 and rc2 with the 9 patches from https://lore.kernel.org/all/20250402202510.432888-1-hdegoede@redhat.com/ No more errors on int3472. But the ov098x40 driver randomly fails to work: ov08x40 i2c-OVTI08F4:00: supply dovdd not found, using dummy regulator ov08x40 i2c-OVTI08F4:00: supply avdd not found, using dummy regulator ov08x40 i2c-OVTI08F4:00: error reading chip-id register: -121 ov08x40 i2c-OVTI08F4:00: probe with driver ov08x40 failed with error -121 Errors -121 are random upon reboot or after rmmod ov08x40 modprobe ov08x40 When there is no error -121, qcam produces a video.
This should now work OOTB starting with Fedora kernels >= kernel-6.14.6-300.fc42, which has the same 9 patches mentioned in comment 11, closing. It would be great if someone can test a kernel >= kernel-6.14.6-300.fc42 on this laptop and confirm that things are really fixed. The colors being washed out and/or the image possibly being a bit over or under exposed is expected behavior ATM, this is due to the software ISP needing more work to improve the image quality. There also is a software-ISP issue where in some cases the auto-exposure algorithm gets into an oscillation and the image flickers pretty badly (bug 2368538).
I compiled on Debian, the latest version, linux 6.15, with the patch. At boot, the ov08x40 module is in error. After restarting the module, I get the flickering image. On Fedora, I have version 6.14.5 without the patch, so I can't test it on Fedora, sorry.
After installing Fedora 42 with the Linux kernel Fedora 6.14.8-300.fc42.x86_64 The patch appears to be installed, but it doesn't work because ov08x40 won't load even after numerous attempts : rmmod ov08x40 modprobe ov08x40 dmesg : ov08x40 i2c-OVTI08F4:00: supply dovdd not found, using dummy regulator ov08x40 i2c-OVTI08F4:00: supply avdd not found, using dummy regulator ov08x40 i2c-OVTI08F4:00: error reading chip-id register: -121 ov08x40 i2c-OVTI08F4:00: probe with driver ov08x40 failed with error -121 (Problem seems to be the sleep timer ?)
(In reply to alcousin from comment #14) > After installing Fedora 42 with the Linux kernel Fedora > 6.14.8-300.fc42.x86_64 > > The patch appears to be installed, but it doesn't work because ov08x40 won't > load even after numerous attempts : > rmmod ov08x40 > modprobe ov08x40 > > dmesg : > ov08x40 i2c-OVTI08F4:00: supply dovdd not found, using dummy regulator > ov08x40 i2c-OVTI08F4:00: supply avdd not found, using dummy regulator > ov08x40 i2c-OVTI08F4:00: error reading chip-id register: -121 > ov08x40 i2c-OVTI08F4:00: probe with driver ov08x40 failed with error -121 > > (Problem seems to be the sleep timer ?) Ok, lets re-open this and investigate why things still do not work. For starters please collect various debug-logs as described here: https://fedoraproject.org/wiki/Changes/X86_MIPI_CameraHwEnablement#How_To_Test and then attach the logs to this bug.
Created attachment 2092657 [details] 14-eu0xxx
Created attachment 2092658 [details] 14-eu0xxx
Created attachment 2092659 [details] 14-eu0xxx i2c-devices
Created attachment 2092660 [details] 14-eu0xxx -spi-devices
(In reply to Hans de Goede from comment #15) > https://fedoraproject.org/wiki/Changes/ > X86_MIPI_CameraHwEnablement#How_To_Test > > and then attach the logs to this bug. I attached logs with 14-eu0xxx in this order : kernel.txt lsusb.txt i2c-devices.txt spi-devices.txt Kernel : Linux fedora 6.14.8-300.fc42.x86_64
Hmm, nothing stands out in the logs. Can you please enable INT3472 dynamic debugging by running: sudo grubby --update-kernel=ALL --args="intel_skl_int3472_discrete.dyndbg" And then reboot and collect a new kernel log ?
Sorry, I thought I did it. I updated everything, then grubby and rebooted. But I got the same results. Sorry, I thought I did it. I updated everything, then grubby and rebooted. But I have the same results, which I'm going to upload. Linux fedora 6.14.9-300.fc42.x86_64
Created attachment 2092674 [details] kernel2
Created attachment 2092679 [details] lsusb2
Created attachment 2092680 [details] i2c-devices2
Created attachment 2092681 [details] spi-devices2
Hmm, the "intel_skl_int3472_discrete.dyndbg" commandline argument is still not there on the kernel commandline. You should have a: /boot/loader/entries/*-6.14.9-300.fc42.x86_64.conf File, can you try editing this as root: sudo su - nano /boot/loader/entries/*-6.14.9-300.fc42.x86_64.conf or if you prefer: vim /boot/loader/entries/*-6.14.9-300.fc42.x86_64.conf And then manually add " intel_skl_int3472_discrete.dyndbg" to the end of the options line. Then reboot and after rebooting run: cat /proc/cmdline and check the option is now there ? And then collect a new kernel log, note only the kernel log will change there is no need to collect a new version of the other logs.
Created attachment 2092703 [details] kernel3 I found, I use debian grub, so grubby was not taken into account. I modified and only kernel.txt attached changes
Is this okay? Hello Hans, if I can help, I'd be happy to help. I'm an old engineer, I've been working with Unix since 1984, and I'm a developer in C and other languages... I'm compiling kerner.org on Debian. If you insist, I can do it on Fedora. Thank you.
Hi, I compiled kernel 6.16-rc1 (Debian) for my HP Spectre 16 Attached is dmesg with kernel arg intel_skl_int3472_discrete.dyn.dbg Sincerely, Duane Kaufman
Created attachment 2093657 [details] HP Spectre 16 kernel 6.16-rc1 dmesg HP Spectre 16 kernel 6.16-rc1 dmesg
(In reply to alcousin from comment #28) > Created attachment 2092703 [details] > kernel3 > > I found, I use debian grub, so grubby was not taken into account. I modified > and only kernel.txt attached changes Thanks, ok so everything looks good but for some reason things are not working. The only theory I can come up with is that the privacy-LED GPIO actually controls some regulator or something like that so that it actually needs to be on during probe. Can you try doing: sudo sh -c 'echo 1 > /sys/class/leds/OVTI08F4_00::privacy_led/brightness' sudo rmmod ov08x40 sudo modprobe ov08x40 and see if these errors: juin 02 14:06:16 fedora kernel: ov08x40 i2c-OVTI08F4:00: error reading chip-id register: -121 juin 02 14:06:16 fedora kernel: ov08x40 i2c-OVTI08F4:00: probe with driver ov08x40 failed with error -121 are gone after the second attempt to load the driver ?
(In reply to Duane Kaufman from comment #31) > Created attachment 2093657 [details] > HP Spectre 16 kernel 6.16-rc1 dmesg > > HP Spectre 16 kernel 6.16-rc1 dmesg Duane, I believe that the camera was working on your laptop with the handshake GPIO patches before, right ? Looking at your log, this seems to be the problem: [ 18.207338] i2c i2c-OVTI08F4:00: deferred probe pending: ov08x40: waiting for fwnode graph endpoint The fwnode for the sensor is populated by the CSI/bridge driver which is part of the ipu6 drivers, and in dmesg I do see the ipu6 driver loading. So it is weird that this is not working. Can you check the .config for your kernel ? I guess that you have CONFIG_IPU_BRIDGE disabled and you need to have that enabled. If that is already enabled please attach your kernel's .config.
(In reply to Hans de Goede from comment #32) > (In reply to alcousin from comment #28) > > are gone after the second attempt to load the driver ? After updating to Linux Fedora 6.14.11-300.fc42.x86_64 I ran the indicated commands (sudo echo 1...), but nothing changed: (sudo dmesg -l err,warn) [ 148.953150] ov08x40 i2c-OVTI08F4:00: supply dovdd not found, using dummy regulator [ 148.953176] ov08x40 i2c-OVTI08F4:00: supply avdd not found, using dummy regulator [ 148.984006] ov08x40 i2c-OVTI08F4:00: error reading chip-id register: -121 [ 148.984455] ov08x40 i2c-OVTI08F4:00: probe with driver ov08x40 failed with error -121 On Debian with kernel 6.16-rc1 compiled, I don't get any errors and "qcam" produces a video. But I'm compiling with optimization and with unnecessary modules reduced.(On rc1, I have another problem, but unrelated to the video. iwlwifi crashes the system, I wait for rc2). Hence, I think it's related to the sleep you indicated here: https://lore.kernel.org/all/20250311114844.25593-1-hdegoede@redhat.com/
(In reply to alcousin from comment #34) > (In reply to Hans de Goede from comment #32) > > (In reply to alcousin from comment #28) > > > > are gone after the second attempt to load the driver ? > > After updating to Linux Fedora 6.14.11-300.fc42.x86_64 > > I ran the indicated commands (sudo echo 1...), but nothing changed: > (sudo dmesg -l err,warn) > [ 148.953150] ov08x40 i2c-OVTI08F4:00: supply dovdd not found, using dummy > regulator > [ 148.953176] ov08x40 i2c-OVTI08F4:00: supply avdd not found, using dummy > regulator > [ 148.984006] ov08x40 i2c-OVTI08F4:00: error reading chip-id register: -121 > [ 148.984455] ov08x40 i2c-OVTI08F4:00: probe with driver ov08x40 failed with > error -121 > > On Debian with kernel 6.16-rc1 compiled, I don't get any errors and "qcam" > produces a video. Interesting and good news, hopefully will get things to work in Fedora too. > But I'm compiling with optimization and with unnecessary > modules reduced.(On rc1, I have another problem, but unrelated to the video. > iwlwifi crashes the system, I wait for rc2). > Hence, I think it's related to the sleep you indicated here: > https://lore.kernel.org/all/20250311114844.25593-1-hdegoede@redhat.com/ That patch has been carried as a downstream patch in the Fedora kernels for a while now, so I do not believe that it is the fix. 6.16-rc1 does have some other ov08x40 driver changes, see: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/media/i2c/ov08x40.c Can you give Fedora's latest 6.16-git build a try: https://koji.fedoraproject.org/koji/buildinfo?buildID=2731743 See here for instructions for installing a Fedora kernel directly from koji: https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt
Created attachment 2093846 [details] dmesg on Fedora test 6.16 rc1 (In reply to Hans de Goede from comment #35) > (In reply to alcousin from comment #34) > > (In reply to Hans de Goede from comment #32) > > > (In reply to alcousin from comment #28) > Can you give Fedora's latest 6.16-git build a try: I tested with version 6.16-rc1 (Same problem with iwlwifi, which I have to blacklist) On Debian it works, on Fedora I have the same problem, error -121. See the attached dmesg report on Fedora. I'll add it on Debian in the next message.
Created attachment 2093847 [details] dmesg Debian test 6.16 rec1 Knowing that I don't have the same modules, on Debian, I added drm and hid, among others. And I compiled with the "-O3 -march=meteorlake -pipe" option.
Okay, I've done some tests. Starting with version 6.16 rc1 from https://koji.fedoraproject.org/koji/buildinfo?buildID=2731743 I took the .config and recompiled it on Debian. The result is error -121, and qcam obviously doesn't work. To be sure, I did the opposite and recompiled my 6.16 rc1 source .config from kernel.org without any other patches using binrpm-pkg. I installed these rpms on Fedora. The result is no more errors, and qcam works on Fedora. So the problem is the modules or options in Fedora's .config, but it's not easy to find which ones.
alcousin, thank you for looking into this. Good work on figuring out that the kernel does work on Fedora with the different .config. Can you attach the config from your working self-build RPMs here ? Then I can compare it with the Fedora kernels config and see if we can figure out what is causing the -121 errors to happen.
Created attachment 2094135 [details] Fedora - my Config - whith nor error ov08x40 Thanks for your help. Attached, configuration file used (/boot/config...) which ensures that ov08x40 has no errors and qcam works on Fedora. I tried to find the modules that are causing the error, but I couldn't find it. Could it also be side effects related to memory or module loading? (Note: I add -meteor to my kernel and use xz instead of zstd, but that's unrelated to the error.)
Created attachment 2094136 [details] Image proof Image proof
(In reply to Duane Kaufman from comment #30) > Hi, > > I compiled kernel 6.16-rc1 (Debian) for my HP Spectre 16 > Attached is dmesg with kernel arg intel_skl_int3472_discrete.dyn.dbg Hello, Duane Kaufman, Can you compile and test with the .config I posted for Hans? It should work with the HP Spectre 16, even though it's not a great configuration for our systems. Yours sincerely
(In reply to alcousin from comment #42) > (In reply to Duane Kaufman from comment #30) > > Hi, > > > > I compiled kernel 6.16-rc1 (Debian) for my HP Spectre 16 > > Attached is dmesg with kernel arg intel_skl_int3472_discrete.dyn.dbg > > > Hello, Duane Kaufman, > > Can you compile and test with the .config I posted for Hans? > It should work with the HP Spectre 16, even though it's not a great > configuration for our systems. > > Yours sincerely Dear alcousin, I used your .config to compile a Debian kernel package on my HP Spectre 16 (2024) laptop. The only thing I changed was turning on CONFIG_EFI_VARS to enable UEFI booting qcam works, as well as cheese my dmesg is attached/uploaded (20250620_dmesg_6.16-rc1-alcousins) Sincerely, Duane
Created attachment 2094544 [details] HP Spectre 16 kernel 6.16-rc1 dmesg (based on alcousin .config)
(In reply to Duane Kaufman from comment #43) > (In reply to alcousin from comment #42) > > (In reply to Duane Kaufman from comment #30) > > qcam works, as well as cheese > > my dmesg is attached/uploaded (20250620_dmesg_6.16-rc1-alcousins) > Thanks Duane, Although I don't quite understand how cheese can work at this point (without v4l2loopback, which requires an update for 6.16, and libcamhal...) (Note: your attachment isn't dmesg, but that's not important.) Yours faithfully
Created attachment 2094835 [details] Kernel version 6.16-rc1 dmesg using alcousin .config
(In reply to alcousin from comment #45) > (In reply to Duane Kaufman from comment #43) > > (In reply to alcousin from comment #42) > > > (In reply to Duane Kaufman from comment #30) > > > > qcam works, as well as cheese > > > > my dmesg is attached/uploaded (20250620_dmesg_6.16-rc1-alcousins) > > > > Thanks Duane, > Although I don't quite understand how cheese can work at this point (without > v4l2loopback, which requires an update for 6.16, and libcamhal...) > (Note: your attachment isn't dmesg, but that's not important.) > Yours faithfully Dear alcousin, I uploaded a more complete dmesg output. For some reason, after running qcam/cheese, the dmesg output is truncated when output. I modified my copy of v4l2loopback to compile under kernel 6.16-rc1, which is how I got cheese to work. Sincerely, Duane Kaufman
Thanks again, Duane. I just tested with 6.16-rc3. The crash with iwlwifi is resolved (with latest firmware), qcam and cheese work even without v4l2loopback, so I said a stupid thing in the last post. However, there are still a few small problems on my 14-eu0xxx; - Occasionally, at boot, I get error -121 in ov08x40 module; however, reloading the module works. - When I first launch qcam, the video is unstable for a few seconds (exposure?). - Stopping and restarting qcam and cheese can cause gnome (or wayland?) to crash, and keyboard and mouse clicks no longer work (though the source may still be elsewhere?). Sincerely, Alain
I'm continuing my tests and modifying the driver code, with the same results, just somme corrections. I've added traces with printk and I notice at boot that the module is called several times randomly (often 3 or 4 times or only one). The traces are at the beginning of ov8x40_probe and then just after the call to ov08x40_check_hwcfg,on power_on, off and at the end of probe. $sudo dmesg | grep ACO [ 4.414080] ACO: probe ov08 000000006a95c4b3 dev 0000000051650ace [ 4.416717] ACO: probe ov08 00000000b339647d dev 0000000051650ace [ 4.424632] ACO: probe ov08 00000000a2a8e8d3 dev 0000000051650ace [ 4.429024] ACO: probe check [ 4.429026] ACO: power_on ov08 00000000a2a8e8d3 dev 0000000051650ace [ 4.463883] ACO: power_off ov08 00000000a2a8e8d3 dev 0000000051650ace [ 4.464012] ACO: end probe
(In reply to alcousin from comment #49) > I'm continuing my tests and modifying the driver code, with the same > results, just somme corrections. > I've added traces with printk and I notice at boot that the module is called > several times randomly (often 3 or 4 times or only one). > The traces are at the beginning of ov8x40_probe and then just after the call > to ov08x40_check_hwcfg,on power_on, off and at the end of probe. Thank you for looking into this. ov08x40_check_hwcfg() failing a couple of times is normal. It is failing with -EPROBE_DEFER which is why the probe is retried later. This is called by this code in ov08x40_check_hwcfg(): /* * Sometimes the fwnode graph is initialized by the bridge driver. * Bridge drivers doing this also add sensor properties, wait for this. */ ep = fwnode_graph_get_next_endpoint(fwnode, NULL); if (!ep) return dev_err_probe(dev, -EPROBE_DEFER, "waiting for fwnode graph endpoint\n"); So basically this is waiting for the ipu6 drivers to load and for the ipu6 code to call ipu_bridge_init(). The next time ov08x40_probe() runs after ipu_bridge_init() completes it will get past this check and then the sensor will get powered-on to check its id-register and if that works the probe() will complete successfully.
Created attachment 2097363 [details] 14-eu0xxx - Modified module ov08x40 Many thanks, Hans, for your help. I'm indeed an idiot, because I didn't understand the comments in the code. Your explanation is clear, and I suspected the module was being called too early. In the attached my code, I modified: . __ov08x40_burst_fill_regs and ov08x40_burst_fill_regs into a single function and corrected the size of the last record if num_write_regs < num_regs . Writes and reads based on other modules, which seems clearer to me and, above all, certified for computers running distributions like Ubuntu. . ov08x40_set_ctrl to retrieve all control returns. I was hoping to fix some problems, but it produces the same result. Otherwise, I don't like the instructions with container_of to find the driver, because if, for example, v4l2 evolves, it risks crashing the modules, since most camera drivers use container_of... Yours faithfully
Hi Hans, I think I've found the issue. The 25 ms delay after the handshake is triggered has to be applied *after* the reset line is deasserted. The current ov08x40_power_on() function enables the dvdd regulator (which drives the handshake pin high and waits for the 25 ms enable_time), then deasserts the reset line and waits 5000-5500 us. If I change the usleep_range to wait at least 25 ms, then the sensor probe succeeds every time. Unfortunately, this goes against your original approach of hiding the need for the delay from the sensor driver.
(In reply to francesco from comment #52) > I think I've found the issue. The 25 ms delay after the handshake is > triggered has to be applied *after* the reset line is deasserted. > > The current ov08x40_power_on() function enables the dvdd regulator (which > drives the handshake pin high and waits for the 25 ms enable_time), then > deasserts the reset line and waits 5000-5500 us. If I change the > usleep_range to wait at least 25 ms, then the sensor probe succeeds every > time. > > Unfortunately, this goes against your original approach of hiding the need > for the delay from the sensor driver. Thank you for looking into this. This sounds like we are getting somewhere. Looking at the dmesg's attached here there are 2 INT3472 devices describing GPIOs for the sensors. One will be for the ov08x40 sensor, while the other is for an infrared-sensor (for Windows Hello auth). Specifically I see: juin 02 14:06:15 fedora kernel: int3472-discrete INT3472:01: Sensor module id: 'YHEC' juin 02 14:06:15 fedora kernel: int3472-discrete INT3472:01: dvdd \_SB.GPI0 pin 65 active-high juin 02 14:06:15 fedora kernel: int3472-discrete INT3472:01: privacy-led \_SB.GPI0 pin 107 active-high juin 02 14:06:15 fedora kernel: int3472-discrete INT3472:02: Sensor module id: 'YHEC' juin 02 14:06:15 fedora kernel: int3472-discrete INT3472:02: reset \_SB.GPI0 pin 209 active-low and also in another dmesg in what seems to be a laptop with a different sensor module: [ 5.428101] int3472-discrete INT3472:01: Sensor module id: 'CJFME62' [ 5.428416] int3472-discrete INT3472:01: dvdd \_SB.GPI0 pin 65 active-high [ 5.428604] int3472-discrete INT3472:01: privacy-led \_SB.GPI0 pin 107 active-high [ 5.430311] int3472-discrete INT3472:02: Sensor module id: 'CJFME62' [ 5.431071] int3472-discrete INT3472:02: reset \_SB.GPI0 pin 209 active-low The 'dvdd' above is the handshake gpio being mapped to a regulator with a 25ms delay. Note that there is no sensor having both a reset and a handshake pin. So what I suspect here is that INT3472:02 is the INT3472 device describing the GPIOs for the ov08x40 sensor and the problem is that it lists the handshake signal as reset making the delay too short. First of all lets confirm this theory. Please boot your system with: "intel_skl_int3472_discrete.dyndbg intel_skl_int3472_common.dyndbg" added to the kernel commandline (without the quotes, these are 2 separate commandline arguments. Under Fedora you can add this by running: sudo grubby --update-kernel=ALL --args="intel_skl_int3472_discrete.dyndbg intel_skl_int3472_common.dyndbg" Before rebooting. This will add a "int3472-discrete INT3472:0x: Sensor name xxxxxx" log message where xxxxxx will be "OVTI08F4:0x" for one of the 2 "INT3472:0x" devices. If my hunch is correct that the issue is that the handshake signal is not described as handshake for the INT3472 device describing the GPIOs for the ov08x40 then the "Sensor name OVTI08F4:0x" message will belong to INT3472:02 which only lists a reset pin and not a handshake pin. In that case we will need to map reset to handshake for the OVTI08F4 sensors, I'll attach a patch to do this.
Hmm, at least for the HP Spectre x360 2-in-1 Laptop 14-eu0xxx model I also see this: juin 02 14:52:01 fedora kernel: ov08x40 i2c-OVTI08F4:00: supply dovdd not found, using dummy regulator juin 02 14:52:01 fedora kernel: ov08x40 i2c-OVTI08F4:00: supply avdd not found, using dummy regulator Note there is no such line for dvdd, which strongly suggest that the pairing of sensor and INT3492 device actually is: OVTI08F4:00 <-> INT3472:01 which makes my theory that the problem is that the reset mapping in INT3472:02 should be a handshake mapping invalid ... So instead it looks like the 25 ms delay used for handshake pins simply is not long enough at least on HP designs with an ov08x40 sensor... Can you please test this change and see if that helps: diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c index 6ec125e55e66..4848ca52167c 100644 --- a/drivers/platform/x86/intel/int3472/discrete.c +++ b/drivers/platform/x86/intel/int3472/discrete.c @@ -337,9 +337,9 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares, break; case INT3472_GPIO_TYPE_HANDSHAKE: - /* Setups using a handshake pin need 25 ms enable delay */ + /* Setups using a handshake pin need 45 ms enable delay */ ret = skl_int3472_register_regulator(int3472, gpio, - 25 * USEC_PER_MSEC, + 45 * USEC_PER_MSEC, con_id, NULL); if (ret) err_msg = "Failed to map handshake to sensor\n"; Note I'm still going to attach the patch to map ov08x40 reset to handshake, but as mentioned that is likely not helpful.
Created attachment 2097851 [details] [PATCH] platform/x86: int3472: For ov08x40 map reset to handshake As mentioned this is likely not what we want / need.
Hello, I applied these 3 modifications: #53 debug int3472 discrete and common #54 modify 25 to 45 ms delay #55 add in struct gpio_map OVTI08F4 After reboot, I have sudo dmesg | grep INT3472 int3472-discrete INT3472:01: Sensor name OVTI08F4:00 int3472-discrete INT3472:01: Sensor module id: 'YHEC' int3472-discrete INT3472:01: dvdd \_SB.GPI0 pin 65 active-high int3472-discrete INT3472:01: [Firmware Bug]: privacy-led \_SB.GPI0 pin number mismatch _DSM 11 resource 107 int3472-discrete INT3472:01: privacy-led \_SB.GPI0 pin 107 active-high int3472-discrete INT3472:02: Sensor name OVTI00AB:00 int3472-discrete INT3472:02: Sensor module id: 'YHEC' int3472-discrete INT3472:02: [Firmware Bug]: reset \_SB.GPI0 pin number mismatch _DSM 49 resource 209 int3472-discrete INT3472:02: reset \_SB.GPI0 pin 209 active-low sudo dmesg | grep OVTI int3472-discrete INT3472:01: Sensor name OVTI08F4:00 int3472-discrete INT3472:02: Sensor name OVTI00AB:00 intel-ipu6 0000:00:05.0: Found supported sensor OVTI08F4:00 ov08x40 i2c-OVTI08F4:00: supply dovdd not found, using dummy regulator ov08x40 i2c-OVTI08F4:00: supply avdd not found, using dummy regulator These are my traces whis my driver that produce the same result than orginal driver: sudo dmesg | grep ACO ACO: probe ov08 000000003651d071 dev 00000000c1e68c4d count 0 ACO: probe ov08 000000003651d071 dev 00000000c1e68c4d count 1 ACO: probe ov08 000000003651d071 dev 00000000c1e68c4d count 2 ACO: probe check mipi_lane 4 ACO: power_on ov08 000000003651d071 ACO: power_off ov08 000000003651d071 ACO: end probe This shows 3 calls to probe, the module not being reloaded (count is a static variable). Another note: when I launch qcam, the image takes a while to stabilize or starts to flash. In this case, my traces show numerous calls to: ACO: set_ctrl ov08 000000003651d071 handler 000000001badd2e8 ctrl_id 9e0903
@alcousin thank you for testing. Can you please collect dmesg output with the new kernel with the extra debug kernel commandline options? Also can you try building a kernel with Fedora's default / standard kernel config with only the 25 to 45 ms delay change? I hope that will fix things with the Fedora kernel config.
Created attachment 2098011 [details] dmesg fedora 14-eu0xxx Hello Hans, The Fedora 6.15.7-200 kernel doesn't work well with my 14-eu0xxx. The Wi-Fi crashes the system at boot, and other minor issues like selinux is in error. ov08x40 is in error -121, even after reloading the module. Attach dmesg on Fedora. But, with my current job, I won't have time to compile on Fedora. On Debian, I'm using kernel 6.16.0-rc7 from kernel.org with my .config. It's easier and faster for me to modify the kernel code on Debian. However, I can create an rpm to install on Fedora. (I'm sorry, I know we're on a Fedora forum, which is a very good distribution.) Sincerely, Alain
@alcousin thank you for the logs. These confirm that the INT3472 to sensor mapping is indeed OVTI08F4:00 <-> INT3472:01, so as I suspected there only is a handshake (and privacy-LED) GPIO defined for the ov08x40 sensor. This means that rather then needing a larger sleep after asserting reset, increasing the delay after setting the handshake pin (through the "dvdd" regulator) should be enough. Assuming Francesco's findings apply to all affected models.
I have prepared and started a test build of the latest Fedora kernel with the 25 -> 45 ms delay increase added as an extra patch. This test-kernel is building here now: https://koji.fedoraproject.org/koji/taskinfo?taskID=135197786 Note this is still building atm, it should be done in a couple of hours. Here are some generic instructions for installing a kernel directly from koji (the Fedora buildsystem): https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt For anyone seeing this issue of probing of the ov08x40 sensor failing with error -121 being reported in dmesg, please give this test kernel a try and report back here if it fixes the issue.
Note the test kernel is done building now, please give it a test run: https://koji.fedoraproject.org/koji/taskinfo?taskID=135197786 https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt
Thanks, Hans. I just tested Linux version 6.15.7-200.ipu6.fc42.x86_64 on my 14-eu0xxx There are indeed no errors on the ov08x40 module and qcam works.
(In reply to Hans de Goede from comment #59) > These confirm that the INT3472 to sensor mapping is indeed OVTI08F4:00 <-> > INT3472:01, so as I suspected there only is a handshake (and privacy-LED) > GPIO defined for the ov08x40 sensor. > > This means that rather then needing a larger sleep after asserting reset, > increasing the delay after setting the handshake pin (through the "dvdd" > regulator) should be enough. Assuming Francesco's findings apply to all > affected models. That makes sense. I assumed there was a Lattice aggregator between the SoC and the two sensors and that both reset and handshake were needed. Indeed, only the handshake and privacy-led are defined. I tested https://koji.fedoraproject.org/koji/taskinfo?taskID=135197786 and it fixes the error -121 for me too (on a 14-eu0xxx). Thank you, Hans!
Created attachment 2098229 [details] [PATCH 1/2] platform/x86: int3472: Rework regulator enable-time handling
Created attachment 2098230 [details] platform/x86: int3472: Increase ov08x40 handshake GPIO delay to 45 ms
@alcousin, @Francesco, thank you both for testing and confirming that increasing the delay to 45 ms fixes things. Increasing the delay everywhere might be a bit of a big hammer. So I've just attached 2 patches intended for upstream which only increase the handshake delay for ov08x40 sensors. I submitting these upstream I would like to see them tested, so I've done another test kernel build now with these 2 patches: https://koji.fedoraproject.org/koji/taskinfo?taskID=135248026 This time the build is already complete and the packages are ready for you to test: https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt Please give this kernel a test run and let me know if this new 6.15.8-200.ipu6.fc42 build still fixes things.
I've tested the new build and can confirm that the sensor is working without any errors. Thank you again, Hans!
I also confirm that it works under fedora as well as patches on kernel 6.16-rc7 on debian.
Thank you both very much for testing the new kernel. I've posted the patches for this upstream now: https://lore.kernel.org/platform-driver-x86/20250725144444.210043-1-hansg@kernel.org/
Great Hans, and thanks to Francesco, who has a lot of knowledge. There are many other topics to work on, such as the settings of the ov08x40 sensor and its use on the web, and the specifications of the second sensor for making the driver...
Hello, I've recently purchased an HP Spectre 16t-aa000 with the ov08x40 sensor. I'm running Arch Linux with kernel 6.16, and I've had to increase the delay from 45ms to 90ms to consistently be able to access my camera with qcam after booting. I tried increments of 5ms until arriving at 90.
(In reply to Steven Eastland from comment #71) > Hello, > > I've recently purchased an HP Spectre 16t-aa000 with the ov08x40 sensor. > > I'm running Arch Linux with kernel 6.16, and I've had to increase the delay > from 45ms to 90ms to consistently be able to access my camera with qcam > after booting. I tried increments of 5ms until arriving at 90. Just to make sure I'm understanding things correctly, you are running a locally build kernel with the following patch applied: https://lore.kernel.org/platform-driver-x86/20250725144444.210043-1-hansg@kernel.org/ with the timeout in the quirk added by the patch increased from 45ms to 90ms ? And that makes things work 100% reliably for you?
(In reply to Hans de Goede from comment #72) > Just to make sure I'm understanding things correctly, you are running > a locally build kernel with the following patch applied: > > https://lore.kernel.org/platform-driver-x86/20250725144444.210043-1- > hansg/ > > with the timeout in the quirk added by the patch increased from 45ms to 90ms > ? > > And that makes things work 100% reliably for you? Yes, that's correct. It was working seemingly 100% reliably on kernel 6.16 and 6.16.1. However, today I built the 6.16.2 kernel with the patch, with the timeout increased to 90ms, and I'm now seeing intermittent success on boot. I'm not sure if there was a change in the newest kernel or if I was simply lucky before and the timeout is not really the issue.
(In reply to Steven Eastland from comment #73) > However, today I built the 6.16.2 kernel with the patch, with the timeout > increased to 90ms, and I'm now seeing intermittent success on boot. I'm not > sure if there was a change in the newest kernel or if I was simply lucky > before and the timeout is not really the issue. That is a good question. If you figure out a way to get this to work reliably please let me know. I would be more then happy to submit any necessary kernel changes like increasing the timeout from 45 ms to 90 ms upstream.
(In reply to Hans de Goede from comment #74) > (In reply to Steven Eastland from comment #73) > > However, today I built the 6.16.2 kernel with the patch, with the timeout > > increased to 90ms, and I'm now seeing intermittent success on boot. I'm not > > sure if there was a change in the newest kernel or if I was simply lucky > > before and the timeout is not really the issue. > > That is a good question. If you figure out a way to get this to work > reliably please let me know. I would be more then happy to submit any > necessary kernel changes like increasing the timeout from 45 ms to 90 ms > upstream. Today I built the 6.16.4 kernel with the timeout set to 90ms, and again with the timeout set to 100ms. I booted each 40 times: with 90ms timeout, I had 9 failed initializations, and with 100ms timeout, I had 4 failed. I may keep trying increasing timeouts to see if I continue to get an increased success rate.
Good news the just released 6.17 kernel has support for the IPU7 CSI2 receiver and the missing USBIO drivers have recently landed in linux-next. I have backported the USBIO drivers + a few other camera fixes to the Fedora 6.17 kernel: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/4105 I've also prepared an updated libcamera-0.5.2 Fedora package with support for IPU7 (Lunar Lake) CSI2 receivers as well as backporting a set of upstream SwStats and AGC fixes, fixing various crashes as well as the bad flicker MIPI camera users have been hitting with libcamera 0.5.2. Together these 2 updates should make the FOSS MIPI camera support work on most Meteor Lake, Lunar Lake and Arrow Lake laptops: https://bodhi.fedoraproject.org/updates/FEDORA-2025-a2b653cff6 https://bodhi.fedoraproject.org/updates/FEDORA-2025-bdeff04027 Please install these updates, disable the proprietary stack from rpmfusion (if installed) by running: "sudo ipu6-driver-select foss", reboot and give the new drivers a try by running qcam, snapshot or video-conferencing in Firefox. After testing please report the testing results in this bug. If things work well for you please leave positive feedback on the updates in bodhi. Note snapshot on Lunar Lake triggers a bug in the LNL Vulkan code, to avoid this start snapshot from a terminal with: GSK_RENDERER=gl snapshot
The patches increasing the handshake delay for the ov08x40 sensor have landed in kernel-6.17.0-63.fc43. If someone still has issues with an ov08x40 sensor on HP laptops please file a new bug.
Many thanks, Hans. I installed Fedora 43 with "6.17.0-63.fc43.x86_64" on an "HP Spectre x360 2-in-1 Laptop 14-eu0xxx/8C15, BIOS F.15". ov08x40 camera, qcam, cheese, and Firefox (https://fr.webcamtests.com/) work. Almost everything works now on this laptop, with a few minor tweaks. The only thing missing is the og0va1b IR camera. Who can we contact for detailed specifications of this camera?
(In reply to alcousin from comment #78) > Almost everything works now on this laptop, with a few minor tweaks. The > only thing missing is the og0va1b IR camera. > Who can we contact for detailed specifications of this camera? I'm afraid that the answer is "no-one" the only way we've gotten sensor programming information so far is through out of tree drivers written by vendors with direct access to omnivision due to them being omnivision customers. You could try seeing if this sensor is maybe used on some Android telephone and there is an Android kernel with a sensor driver for it. Otherwise I see no way to get this to work.
(In reply to Hans de Goede from comment #79) > You could try seeing if this sensor is maybe used on some Android telephone > and there is an Android kernel with a sensor driver for it. Otherwise I see > no way to get this to work. Thanks for your feedback, Hans. I searched for Android or even ChromeOS, but I couldn't find anything. This sensor is used by other brands, such as Dell, for Windows Hello. Otherwise, it's sold by Omnivision for industry and drones. I'm sure it's used under Linux, but without publishing the specifications and sources. Aren't there Linux teams working with manufacturers? And I don't really understand the manufacturers' policies if they want to sell their products, because it seems to me that it would be in their interest to support Linux even with just minimal drivers.
(In reply to alcousin from comment #80) > Aren't there Linux teams working with manufacturers? The Intel Linux camera team works with the sensor manufacturers, this is how we have drivers for most of the normal/standard (color) sensors, although it is up to the community the actually mainline the drivers which Intel posts here: https://github.com/intel/ipu6-drivers/tree/master/drivers/media/i2c But the Intel Linux camera team does not work on supporting the black-white / IR sensors. They only support the normal sensors.
I appreciate Hans. I have "HP Spectre x360 2-in-1 Laptop 14t-eu000". I have tested with nightly build fedora 43 with kernel 6.17.0-63.fc43.x86_64. Eventually camera worked out of the box. Before, i tested with linux arch and install ipu6 driver stack, but camera only show with qcam with flickering , other apps didnt show, or overload cpu to 100. But now tested with camera app and firefox , camera is good, no flickering. Now snapshot camera app and pipewire getting 20-30 percent load of cpu of core for each app. And some problem with camera , it become overly light in brighter room and circular light stop appear om the center of picture. Here is some info: top: 14354 liveuser 20 0 3318592 146740 104104 S 28.5 0.5 0:16.51 snapshot 13732 liveuser 20 0 721740 31548 22480 S 27.2 0.1 0:21.46 pipewire qcam: liveuser@localhost-live:~$ qcam [0:46:44.947458087] [14762] INFO Camera camera_manager.cpp:330 libcamera v0.5.2 [0:46:44.972889524] [14774] ERROR V4L2 v4l2_subdevice.cpp:1198 'ov08x40 3-0036': Unable to get rectangle 2 on pad 0/0: Inappropriate ioctl for device [0:46:44.972912657] [14774] WARN CameraSensor camera_sensor_legacy.cpp:401 'ov08x40 3-0036': The PixelArraySize property has been defaulted to 3856x2416 [0:46:44.972918429] [14774] ERROR V4L2 v4l2_subdevice.cpp:1198 'ov08x40 3-0036': Unable to get rectangle 1 on pad 0/0: Inappropriate ioctl for device [0:46:44.972923601] [14774] WARN CameraSensor camera_sensor_legacy.cpp:412 'ov08x40 3-0036': The PixelArrayActiveAreas property has been defaulted to (0, 0)/3856x2416 [0:46:44.972929178] [14774] ERROR V4L2 v4l2_subdevice.cpp:1198 'ov08x40 3-0036': Unable to get rectangle 0 on pad 0/0: Inappropriate ioctl for device [0:46:44.972933246] [14774] WARN CameraSensor camera_sensor_legacy.cpp:420 'ov08x40 3-0036': Failed to retrieve the sensor crop rectangle [0:46:44.972936795] [14774] WARN CameraSensor camera_sensor_legacy.cpp:426 'ov08x40 3-0036': The sensor kernel driver needs to be fixed [0:46:44.972939932] [14774] WARN CameraSensor camera_sensor_legacy.cpp:428 'ov08x40 3-0036': See Documentation/sensor_driver_requirements.rst in the libcamera sources for more information [0:46:44.973205398] [14774] WARN CameraSensorProperties camera_sensor_properties.cpp:484 No static properties available for 'ov08x40' [0:46:44.973213290] [14774] WARN CameraSensorProperties camera_sensor_properties.cpp:486 Please consider updating the camera sensor properties database [0:46:44.973221600] [14774] WARN CameraSensor camera_sensor_legacy.cpp:501 'ov08x40 3-0036': No sensor delays found in static properties. Assuming unverified defaults. [0:46:44.977839653] [14774] WARN IPAProxy ipa_proxy.cpp:177 Configuration file 'ov08x40.yaml' not found for IPA module 'simple', falling back to 'uncalibrated.yaml' [0:46:44.977894553] [14774] ERROR V4L2 v4l2_subdevice.cpp:1198 'ov08x40 3-0036': Unable to get rectangle 0 on pad 0/0: Inappropriate ioctl for device [0:46:44.977907442] [14774] WARN CameraSensor camera_sensor_legacy.cpp:880 'ov08x40 3-0036': The analogue crop rectangle has been defaulted to the active area size [0:46:44.991562323] [14775] INFO IPAProxySoftWorker soft_ipa_proxy_worker.cpp:448 Starting worker for IPA module /usr/lib64/libcamera/ipa/ipa_soft_simple.so with IPC fd = 35 [0:46:44.992228463] [14775] WARN IPASoft soft_simple.cpp:103 IPASoft: Failed to create camera sensor helper for ov08x40 [0:46:44.992698404] [14774] INFO Camera camera_manager.cpp:220 Adding camera '\_SB_.PC00.LNK0' for pipeline handler simple [0:46:45.017089334] [14762] INFO Camera camera.cpp:1215 configuring streams: (0) 3848x2416-ABGR8888/Unset [0:46:45.017494084] [14775] INFO IPASoft soft_simple.cpp:269 IPASoft: Exposure 4-4992, gain 128-1984 (1) Zero-copy enabled [0:46:47.584918314] [14778] INFO Debayer debayer_cpu.cpp:831 Processed 30 frames in 1066446us, 35548 us/frame And if you need additinal testing or logs I can provide them. I can also give temporary access to this device to inspect hardware and logs directly if that help camera issue debugging. You can contact me directly at aaavazxonov (at) gmail (dot) com.
(In reply to Hans de Goede from comment #81) > But the Intel Linux camera team does not work on supporting the black-white > / IR sensors. They only support the normal sensors. Thank you, Hans, for your explanation and the actions you've taken to make ours and my laptop work. I see it with Microsoft converging toward Linux, Intel, AMD, NVIDIA... Companies need direction, a goal; is this the free world? Excuse me, I'm French, and I operate with philosophy; I hope the world wants to be free to undertake and trade. Free doesn't mean not paying for the work you do, quite the opposite. So thank you, Hans, for the help you provide.