OV2740 camera/webcam sensor on X1 Nano Gen2 #55
Comments
|
Further updates. I wrote an AUR package and made it available in gitlab that compiles the kernel using your patches and the method described in the repo readme here. FYI, I don't completely understand the current division between this repo and the ivsc-driver, I understand the ivsc code was merged into this repo? The kernel build does not currently apply the changes in that repo. Booting from this modified kernel and attempting to load the correct modules as described above results in the same hang and the following stack trace can be found in the dmesg logs: This appears very similar to the issue described in #48, with the difference being that the IOMMU/gpio patches have been applied. |
polair
changed the title
|
I have been working on making the ipu6-driver stack work on a Lenovo Thinkpad X1 Yoga gen 7 (alderlake) with a 6.0 kernel and using the INT3472 mainline kernel driver for power-control. I have submitted the following fixes for this, I believe these should also fix things not working on the X1 Nano Gen2: #58 Note this relies on the mainline kernel itself also being build with the 2 patches from ipu6-drivers/patch. And if you look at the |
|
Thanks a lot for the information and reply. I tried to get the camera operational by building the kernel with the patches (applying a custom patch via AUR/PKGBUILD) and then I built your branch as DKMS modules, thinking I was being clever. I did it this way since I ran into issues building the kernel manually with ipu6/ivsc built in, surely a problem with my build script. That said, compiling your branches as DKMS modules and then loading the patched kernel... I still get a hang on module load. It seems to be when the module tries to load the firmware from the binary blobs. Here is the stack trace: |
|
@jwrdegoede Thanks for taking the time to reply. I understand you're definitely not Intel webcam support. I had made a late night mistake in my build script. I can confirm that your patches allow me to load the modules. Now if only I could figure out my issue with v4I2 opening the camera.. I get the following error when using gst-launch: Which implies that the hal package isn't somehow providing the correct something? I have the following files provided by that package: When I try to run it with v4l2-relayd I get a different error that I haven't been able to debug, which also implies there is something going on with the gstreamer->hal communication: |
|
The following works for me (as a regular user): Note that I do not pass a |
|
Thanks for continuing to reply! I don't have the device Looking at dmesg and grepping for output with "vsc" doesn't show anything. It seems that this is something to do with the vsc modules/firmware from ivsc-driver. I'm both doing the merge described in the ipu6-driver README as well as installing the ivsc-driver package itself. Maybe this creates a conflict? |
|
Did you rebuild your main kernel with the IOMMU + int3472-gpio + https://lore.kernel.org/linux-acpi/20221022150722.31787-1-hdegoede@redhat.com/ patches ? You need the int3472-gpio + my patch to get the sensors to show up in |
|
@jwrdegoede OK. It works! Deleting previous comment. The key was your final one line patch. I can confirm that your pull request fixes operational issues with the OV2740 sensor on the X1 nano. My procedure: Build kernel with the three patches, IOMMU, GPIO, and your latt2021. Clone ipu6-drivers with your pull request and apply ivsc patchset as described in README to then build as DKMS, clone ivsc-driver with your pull request and build as DKMS. Packages required otherwise. intel-ivsc-firmware, intel-ipu6-camera-bin, v4l2-relayd, and icamerasrc. I'm going to write up the specifics on the Arch linux forum/wiki when I get some time, it's not exactly straightforward. Hopefully more users will mean some other bugs get ironed out, because... It's definitely not smooth sailing from there, there are issues with the icamerasrc/hal and v4l2-relayd crashed on me twice in an hour. But the camera is on and streaming, which is satisfying. It would be great if I didn't have to carry another laptop for video calls. :| edit: ok, I figured this out. The udev rules for the hal package wreak havoc on various libraries from the camera-bin, icamerasrc, and hal packages. It seems that there are some build flags necessary but the Arch packages work fine if you just don't install the udev rules. Interestingly (and maybe I shouldn't dare to provide compliments given the Linux drivers for year+ old hardware are in such a sad state), the quality of the camera feed is better than anything I've seen in a laptop. So kudos to Intel there, from a photographer. The contrast, resolution, and clarity are all very very nice. If only they cared more about Linux/FOSS. |
|
Interesting that v4l2-relayd works for you, because I have not got that working yet (under Fedora) may I ask how you have installed v4l2-relayed? And can you share your /etc/default/v4l2-relayd file ? |
|
@jwrdegoede I installed it via custom PKGBUILD. I can provide it here if it would help. It took some tweaking and understanding of the options:
|
|
@jwrdegoede I'm not done here though. I wasn't able to fix the sleep issue. Does suspend work fine for you? It totally borks the state of the ipu modules, even if I unload everything before sleep. If I unload and try to reload them after wake, I get a stack trace similar to the one before I tried your patches. Weirdly, the only way I can repeat the sleep behaviour but without sleeping to try to debug, is to rmmod the i2c/gpio/ljca modules and then modprobe the full stack starting there up to ipu6/ov2740. Then ipu6_isys hangs and I have to reboot. I spent way too much time rmmodding/modprobing various related modules to see if I could figure out the ordering issue to no avail. I would love to understand better the way kernel/hardware initialization works so I could debug it. But my day job is radically far away from this. After sleep, the state of the i2/devices all looks the same. /dev/ipu-psys0 is there. But the camera can't be detected. |
|
OK. I was finally able to get a stack trace from the sleep issue and then the reloading of the modules. There seems to be some relevant information. Maybe this weekend I'll consider this a hobby and dig through the code a bit to try to understand it: |
|
I'm now in the same boat (X1 Nano Gen2 without working camera).
But Now here comes now a new error message I was not able to find anything about in this context yet.
Any hint in which direction I could further loot at? Thanks in advance |
|
Found the issue. I was loading the ov2740 from the mainline kernel, and not from the ipu6 driver (installed via dkms). |
|
@RoXXoR I made the attempt to update to the 6.2 kernel recently and couldn't get it to work. Can you describe exactly how you 'removed' ov2740.ko' from the mainline kernel in more detail? Thanks much. |
|
@polair initially brute force renamed /lib/modules/6.2.2-ipu6mod/kernel/drivers/media/i2c/ov2740.ko to ov2740.ko.old and thus modprobe loaded ov2740.ko from /lib/modules/6.2.3-ipu6mod/updates/drivers/media/i2c/ (dkms build modules). Cheers. |
|
@RoXXoR great, thanks much! |
v4l2-relayd needs a patched v4l2-loopback which send events when the other end of the loopback-device is opened/closed. @smallorange has been working on getting the necessary changes merged into v4l2-loopback upstream (https://github.com/umlaeute/v4l2loopback). The changes are upstream now but the latest v4l2-loopback code introduces some new issues with v4l2-relayd. According to: rpmfusion/v4l2loopback-kmod#2 umlaeute/v4l2loopback@a669686 is the v4l2-loopback commit to use to get a working v4l2-relayd. At least until the issues with the latest latest v4l2-loopback changes are resolved. |
|
Is there a generic way around the observed relayd issue? I'm seeing the same issue on a ThinkPad X1 Gen 10 with a custom v4l2 loopback module built from the commit above: The commit This command starts, after indicating a GST plugin path with gst-launch-1.0 icamerasrc buffer-count=7 device-name=ov2740-uf ! video/x-raw,format=NV12,width=1280,height=720 ! v4l2sink device=/dev/video1Subsequent runs show a different error on quitting: The AIQD file names are first recognised, and then not anymore. With relayd not working, this has no chance of working in Cheese or Firefox. Maybe relayd also needs an equivalent for |
Hi all. Thank you for supporting this hardware on an open source OS. It's beyond appreciated. I've attempted to build your software/DKMS drivers on Arch linux for the Alder Lake IPU6 with the OV2740 sensor. Using the most recently available git packages, I'm unable to load the intel-ipu6-psys and intel-ipu6-isys modules. modprobe for intel-ipu6 itself loads the module and after this I'm able to load the ov2740 module but not with the psys/isys modules.
I'm uncertain what other feedback to provide as with the module hang I've been unable to get further debug information. I would be very happy to provide any feedback you need to troubleshoot.
Also, are you able to comment on the "intel_iommu=off" kernel option? Is this necessary?
Take care.
The text was updated successfully, but these errors were encountered: