search

endeavour / DellXps7390-2in1-Manjaro-Linux-Fixes

Kernel patches and tweaks to get the Dell XPS 7390 2-in-1 with 10th Gen Intel CPUs functioning on Manjaro Linux
23 stars 3 forks source link

Webcam Not Working #6

Open dkout opened 4 years ago

dkout commented 4 years ago

I have tried installing both Ubuntu and Manjaro but the webcam does not seem to work on either (while it works on Windows). It seems that the webcam is not even being recognized by the system. Any thoughts on how this might be fixed? Would a kernel update solve this in the future?

Thanks!

kbingham commented 3 years ago

You'd need to identify what commits are adding the driver to the tree you are testing, and cherry-pick them all to the top a mainline kernel. Ideally - that would be on top of the master branch at git://linuxtv.org/media_tree.git.

Then when they're all on the top of 5.x, build and test it of course until you get to the same results you have here.

kbingham commented 3 years ago

@typhoe It might also be worth summarising here what you have done to be able to get this far. Which repostiory, branch, firmware, configuration etc you used to be able to build and load those modules successfully, so that others might also be able to try to rebase.

typhoe commented 3 years ago

For reference: How to build ipu4p drivers on Intel-LTS v4.19 kernel on Manjaro linux

Create a working dir

WorkingDir=~/webcam
mkdir -p ${WorkingDir}
cd ${WorkingDir}

First, get firmware blob from latest Intel 2D Imaging Driver for Windows 10 from Dell website

https://www.dell.com/support/home/en-us/drivers/driversdetails?driverid=gdd1w&oscode=wt64a&productcode=xps-13-7390-2-in-1-laptop&lwp=rt

Download driver, extract the binary blob and copy it under /usr/lib/firmware/ipu4_cpd_b0.bin

cd ${WorkingDir} && wget -c "https://dl.dell.com/FOLDER05745912M/1/Intel-2D-Imaging-Driver_GDD1W_WIN_42.17134.3.10744_A01.EXE"
unzip -j -d ${WorkingDir} ${WorkingDir}/Intel-2D-Imaging-Driver_GDD1W_WIN_42.17134.3.10744_A01.EXE Files/x64/cpd_component_signed.bin
sudo cp ${WorkingDir}/cpd_component_signed /usr/lib/firmware/ipu4_cpd_b0.bin

The blob firmware that we have will be too recent for the driver we will build. To disable the version check, add a default option to modprobe

echo "options intel_ipu4p fw_version_check=0" |sudo tee /etc/modprobe.d/ipu4.conf

Get kernel source for branch 4.19/base from Intel-LTS official repo

https://github.com/intel/linux-intel-lts/tree/4.19/base/drivers/media/pci/intel/ipu4

git clone -b 4.19/base https://github.com/intel/linux-intel-lts.git

To be able to use the default configuration from Manjaro kernel, I reinstall old kernel 4.19

sudo pacman -S linux419 linux419-headers

Then reboot on 4.19 kernel (beware, no wifi and video blinking!) And create a copy of the /proc/config.gz file for futur uses

WorkingDir=~/webcam
cp /proc/config.gz ${WorkingDir}/config_4.19.gz

Now, you can either keep Manjaro kernel 4.19 or remove it... but I choose to remove it and reboot on a fully working kernel

sudo pacman -R linux419 linux419-headers

Generate a .config file from manjaro v4.19 kernel default options

WorkingDir=~/webcam
zcat ${WorkingDir}/config_4.19.gz > ${WorkingDir}/linux-intel-lts/.config

Add IPU4 options to .config file (I used those suggested by @kitakar5525)

https://github.com/endeavour/DellXps7390-2in1-Manjaro-Linux-Fixes/issues/6#issuecomment-715734611


cat <<EOF >>${WorkingDir}/linux-intel-lts/.config
#
# IPU4
#
CONFIG_VIDEO_INTEL_IPU=m
#
# select VIDEO_INTEL_IPU4 if your PCI ID is 0x5a88
# select VIDEO_INTEL_IPU4P if your PCI ID is 0x8a19 (the DELL XPS13 7390 I have is in this case)
# https://github.com/intel/linux-intel-lts/blob/bd16f3c70d1773b1811eeb77fc7ca68f88208d2b/drivers/media/pci/intel/ipu.h#L17-L21
#
CONFIG_VIDEO_INTEL_IPU4P=y
CONFIG_VIDEO_INTEL_IPU_FW_LIB=y

#

Not sure what exactly these options mean

# CONFIG_VIDEO_INTEL_IPU_SOC=y CONFIG_VIDEO_INTEL_ICI=n # <= Had to disable this one or I cannot build the modules

#

camera sensors

#

CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set

CONFIG_VIDEO_CRLMODULE=m CONFIG_VIDEO_CRLMODULE_LITE=m EOF


Tag the new kernel we will build
```sh
TagKernel="-IPU4-TEST"
sed -i 's,^CONFIG_LOCALVERSION=.*,CONFIG_LOCALVERSION="'${TagKernel}'",' ${WorkingDir}/linux-intel-lts/.config
KernelName=$(awk '/^VERSION/{print $3};/^PATCHLEVEL/{print "."$3};/^SUBLEVEL/{print "."$3};/^EXTRAVERSION/{if ($3 != "") {print "."$3}}' ${WorkingDir}/linux-intel-lts/Makefile |paste -sd "")$(awk -F\" '/^CONFIG_LOCALVERSION/{if ($2 != "") {print $2}}' ${WorkingDir}/linux-intel-lts/.config)+
echo "KernelName will be ${KernelName}"

If we already did some build tests, clean building environment

make clean

Make new kernel (option -j nb_vcpu+1 to speed up things, or -2 if you want your PC to let you keep working in the meantime) Beware it takes between 20 to 60 minutes depending of your choice First time you'll try the command, choose default options if asked any (just pressed enter for each choices)

make -j$(($(nproc)+1))

Install kernel (will only copy vmlinuz and System.map files in /boot)

sudo make install

Install modules (they will be copied to /usr/lib/modules/${KernelName})

sudo make modules_install

Rename System.map et vmlinuz

sudo mv /boot/System.map /boot/System.map-${KernelName}
sudo mv /boot/vmlinuz /boot/vmlinuz-${KernelName}

Generate initramfs (option -k is from OurKernelName)

sudo mkinitcpio -k ${KernelName} -g /boot/initramfs-${KernelName}.img

Manjaro uses grub, so update grub menu

sudo update-grub

And now reboot on the new built kernel. If everything is ok, you should be able to see the module has been loaded (You should obtain results similar to these: https://github.com/endeavour/DellXps7390-2in1-Manjaro-Linux-Fixes/issues/6#issuecomment-719583122 )

lsmod |grep ipu4
journalctl -b |grep intel-ipu4

You can also use the script from @kbingham to test your module (require graphviz package and should be run with sudo) https://gist.github.com/kbingham/be28a67831c26158bdb4ab2a48e707d4

To clean and restore grub (remove the built kernel entry)

sudo rm -Rf /boot/*${KernelName}* /usr/lib/modules/${KernelName} && sudo update-grub
typhoe commented 3 years ago

I added just above the howto to reproduce my steps as you asked.

And I managed to build a basic 5.10-rc1 kernel from https://git.linuxtv.org/media_tree.git (without ipu4 support) and boot it.

Now, I'll try to see if I can indeed add the drivers from the Intel-LTS 4.19 repo branch and get them to work.

I'll post again if I manage anything.

kitakar5525 commented 3 years ago

Glad to see that the driver seems to be working on Intel's v4.19 ! So, now it's really interesting to try to port the driver to the latest stable kernel series.

I opened a issue for collecting camera data (mainly for ACPI data): https://github.com/linux-surface/linux-surface/issues/326 It's interesting to see data from other than Surface devices. Can anyone run the module and attach the output? (here or to the above link or to my repo)

typhoe commented 3 years ago

@kitakar5525 Just posted the result file on the other thread. Made the module with official Manjaro kernel 5.8. With the 4.19 kernel (the one I build with ipu4 module), I couldn't make the module, I got error with the make command.

Regarding porting the ipu4 driver to 5.10 kernel, I'm working on it but to be honest, I suck at using git and I have to redo everything I did while cherry-picking the commits (around 150) because I made some mistakes with my previous attempts and well, it doesn't work :-1:

typhoe commented 3 years ago

Well, unfortunately I can't manage to build the driver on 5.10 kernel. Here is a clone of https://git.linuxtv.org/media_tree.git with a new branch ipu4 with the commits I cherry-picked from https://github.com/intel/linux-intel-lts/tree/4.19/base :

https://github.com/typhoe/kernel-ipu4/compare/ipu4

After cherry-picking all the (estimated) relevant commits from intel 4.19 repo, and correcting a few thing (like ---help--- syntax to simply help in Kconfig file), I can launch the make command, but get errors in the process.

Here the log if anyone has an idea (and to be clear, I don't know C programming). make_5.10_err.log Files drivers/media/pci/intel/ipu4/../ipu-dma.c are identicals in my 5.10 git tree and in the intel 4.19 tree so the problem doesn't seem to be in that file...

kbingham commented 3 years ago

I've started looking at this but there is a lot of rework required to deal with DMA api changes. It looks like a lot of that happened at v5.7, so we could try rebasing before that to start with, otherwise we'll have to bite the bullet and work through all the DMA api updates required.

kitakar5525 commented 3 years ago

@typhoe

Just posted the result file on the other thread.

Thanks again. For the record, it's here: result_XPS_13_7390_2-in-1_08B0@v1.1.md

I leave here what I noticed about the dump:

kern  :info  : [  176.442774] get_acpi_pmic_data(): ==================== INT346F:02 (PMIC) ====================
[...]
kern  :info  : [  176.443164] ACPI path: \_SB_.PCI0.DSC1
kern  :info  : [  176.443165] ACPI device name: INT346F:02
kern  :info  : [  176.443174] print_pmic_i2c_dev_name(): (i2c dev not found as expected (DISCRETE))

EDIT: found OV02A10 under development: [PATCH v15 2/2] media: i2c: Add OV02A10 image sensor driver I'm not sure how similar it is to 01A0, but we could use it as a base.

typhoe commented 3 years ago

Hi,

@kbingham can I ask if there has been any progress on the rebasing ? I would really like to be more proactive but that's so far above my knowledge...

Thank you very much

kbingham commented 3 years ago

I'm afraid I have no resources available to work on the IPU4.

typhoe commented 3 years ago

Thank you for your answer, and I understand... It's already an old hardware and not a lot a people seems to be interested. Anyway, thank you for all the time you took to help us!

ChenSun-Phys commented 3 years ago

Hi, @kbingham thanks for the update. I also wonder if there's any way that I could help. I mean I have the hardware and know some very basics of Linux debugging, but never wrote any code on the kernel/driver level. As someone already mentioned above, perhaps we can either help test some code if you could provide some instructions or share my hardware remotely for some test runs.

kbingham commented 3 years ago

anyone willing to work on this needs to work through getting the ipu4 driver to compile in the latest kernel. From reading above it sounds like updates are required to the code so you would need to work through the compile errors one by one and identify the correct way to fix them.

It seems that may involve updating code to use newer or different kernel APIs, but if you know c that's all you need. The APIs will have lots of example usage through out the kernel, so it's a matter of searching and reading documentation.

You may also find support in the #v4l channel on irc

vdwijngaert commented 3 years ago

The linux-surface project appears to be making some progress. Can we do something with that?

kbingham commented 3 years ago

That's what we're working on. The Linux Surface has an IPU3 (mostly), and is the platform that we are able to support currently. See https://github.com/linux-surface/linux-surface/wiki/Camera-Support which has the tables of currently supported hardware.

You can note that the Surface Book 3 (SB3) and Surface Pro 7 (SP7) has an IPU4. We can't support those until there is a kernel driver available. Intel pushed the IPU3 driver into the kernel, but I don't have any knowledge of them doing the same for the IPU4. As highlighted in this thread, there are some code drop releases of the IPU4 drivers, but the architecture of the IPU4 is quite different from the IPU3.

In summary: To support cameras on an IPU4 the following must be done:

  1. IPU4 driver rebased and functioning on a new/recent Linux kernel. (and ideally posted for review/integration to linux-media)
  2. ACPI bridging of the sensors to the IPU4 driver (similar to work which is done for the CIO2 bridge driver)
  3. IPU4 pipeline handler support in libcamera (could be based on IPU3 of course, but will be different)
  4. IPU4 Algorithm development in libcamera (likely based on the IPU3

We're stuck at step 1 here in this thread.

vdwijngaert commented 3 years ago

That's what we're working on. The Linux Surface has an IPU3 (mostly), and is the platform that we are able to support currently. See https://github.com/linux-surface/linux-surface/wiki/Camera-Support which has the tables of currently supported hardware.

You can note that the Surface Book 3 (SB3) and Surface Pro 7 (SP7) has an IPU4. We can't support those until there is a kernel driver available. Intel pushed the IPU3 driver into the kernel, but I don't have any knowledge of them doing the same for the IPU4. As highlighted in this thread, there are some code drop releases of the IPU4 drivers, but the architecture of the IPU4 is quite different from the IPU3.

In summary: To support cameras on an IPU4 the following must be done:

  1. IPU4 driver rebased and functioning on a new/recent Linux kernel. (and ideally posted for review/integration to linux-media)
  2. ACPI bridging of the sensors to the IPU4 driver (similar to work which is done for the CIO2 bridge driver)
  3. IPU4 pipeline handler support in libcamera (could be based on IPU3 of course, but will be different)
  4. IPU4 Algorithm development in libcamera (likely based on the IPU3

We're stuck at step 1 here in this thread.

Thanks for the clarification!

QMeqGR commented 3 years ago

Has anyone tried to set up PCI passthrough in a VM under a linux host to get the webcam working? This might be an option to use the camera.

Cybso commented 3 years ago

For the record and for others who try to google this issue:

The new Latitude 9420 (Tiger Lake) comes with "Multimedia controller: Intel Corporation Device 9a19 [8086:9a19]" which seems to suffer from the same issue as 8a19.

vladjohnson commented 2 years ago

Any updates? Surface-linux got a kernel to support ov5693...

kbingham commented 2 years ago

@vladivanov20 The camera system on this device is an IPU4.

The Surfaces use an IPU3, (excepting one model, which has an IPU4, I think, and is therefore unsupported, like this one).

Supporting IPU4 is an exercise that will likely take many months of effort. It is not being worked on, that I'm aware of, and has no sponsorship to do so.

I'm happy to help anyone who will commit to working on this, and I've provided general steps that need to be followed above.

So we're still stuck waiting on someone who can offer to do step 1 as mentioned here: https://github.com/endeavour/DellXps7390-2in1-Manjaro-Linux-Fixes/issues/6#issuecomment-787774707

rkakrik commented 2 years ago

Is there any news?

kbingham commented 2 years ago

https://github.com/endeavour/DellXps7390-2in1-Manjaro-Linux-Fixes/issues/6#issuecomment-956048074

We're still at step 1, waiting for someone to step up, and try to do the kernel work, or find a (big corporate) sponsor to fund the work to be done.

konturn commented 2 years ago

Hi all--decided to take a stab at this. I forked @typhoe's repo where they built the ipu4 drivers on kernel version 4.19. I made some code changes to get the build working with kernel version 5.10. You can view the fork here: https://github.com/konturn/kernel-ipu4/tree/ipu4

Anyways, while the driver and firmware blob appear to be loaded in correctly, I'm still running into some issues with the script provided by @kbingham. Relevant outputs:

lsmod|grep ipu4
intel_ipu4p_mmu        20480  1
intel_ipu4p            94208  1 intel_ipu4p_mmu
journalctl -b |grep intel-ipu4
Nov 07 22:07:45 XPS-13 kernel: intel-ipu4 intel-ipu: enabling device (0000 -> 0002)
Nov 07 22:07:45 XPS-13 kernel: intel-ipu4 intel-ipu: Device 0x8a19 (rev: 0x3)
Nov 07 22:07:45 XPS-13 kernel: intel-ipu4 intel-ipu: physical base address 0x603c000000
Nov 07 22:07:45 XPS-13 kernel: intel-ipu4 intel-ipu: mapped as: 0x00000000b9fef652
Nov 07 22:07:45 XPS-13 kernel: intel-ipu4 intel-ipu: IPU in secure mode
Nov 07 22:07:45 XPS-13 kernel: intel-ipu4 intel-ipu: cpd file name: ipu4p_cpd.bin
Nov 07 22:07:45 XPS-13 kernel: intel-ipu4 intel-ipu: Moduledata version: 20180316, library version: 20181222
Nov 07 22:07:45 XPS-13 kernel: intel-ipu4 intel-ipu: CSS release: 20181222
Nov 07 22:07:45 XPS-13 kernel: intel-ipu4 intel-ipu: IPU driver verion 1.0

The script output:

cat: '/sys/class/video4linux/v4l*/name': No such file or directory
cat: '/sys/class/video4linux/video*/name': No such file or directory
v4l*:
video*:
cat: '/sys/bus/media/devices/media*/model': No such file or directory
media*:
/dev/media*:
Failed to enumerate /dev/media* (-2)

Error: <stdin>: syntax error in line 1 near 'Failed'

Looking at @typhoe's output for lsmod, I'm assuming the issue is that the intel_ipu4p_psys/intel_ipu4p_isys drivers aren't being loaded in? Anyone have any ideas on how to fix this?

konturn commented 2 years ago

Couple of updates: I can enable intel_ipu4p_psys via modprobe, but I get the following error in dmesg:

intel-ipu4-psys intel-ipu4-psys0: ipu_bus_get_group: no iommu available

Also, the following null pointer dereference shows up in dmesg at boot:

[   10.391659] BUG: kernel NULL pointer dereference, address: 0000000000000000
[   10.391702] #PF: supervisor instruction fetch in kernel mode
[   10.391730] #PF: error_code(0x0010) - not-present page
[   10.391757] PGD 0 P4D 0 
[   10.391771] Oops: 0010 [#1] PREEMPT SMP NOPTI
[   10.391795] CPU: 4 PID: 459 Comm: systemd-udevd Not tainted 5.10.0-rc1-IPU4-TEST-14742-g02cdee326da5-dirty #8
[   10.391845] Hardware name: Dell Inc. XPS 13 7390 2-in-1/06CDVY, BIOS 1.5.0 06/05/2020
[   10.391887] RIP: 0010:0x0
[   10.391901] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
[   10.391935] RSP: 0018:ffffad12008d3b60 EFLAGS: 00010202
[   10.391964] RAX: 0000000000000000 RBX: ffff8955c4d18f40 RCX: 0000000000000001
[   10.392003] RDX: ffffffff93a4d8a0 RSI: ffffffff92bc6754 RDI: ffff8955e603cc00
[   10.392042] RBP: ffff8955e603cc00 R08: 0000000000000040 R09: ffff8955c4d18f40
[   10.392076] R10: ffff8955e6c68d00 R11: 0000000000000000 R12: ffffffffc0ca50e0
[   10.392109] R13: 0000000000000000 R14: ffffad12008d3c00 R15: 00000000ffffffea
[   10.392148] FS:  00007f0527bafa40(0000) GS:ffff89593f700000(0000) knlGS:0000000000000000
[   10.392189] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   10.392220] CR2: ffffffffffffffd6 CR3: 000000011dc20004 CR4: 0000000000770ee0
[   10.392258] PKRU: 55555554
[   10.392274] Call Trace:
[   10.392293]  __iommu_probe_device+0x5b/0x250
[   10.392313]  ? __iommu_probe_device+0x250/0x250
[   10.392338]  probe_iommu_group+0x2d/0x40
[   10.392359]  bus_for_each_dev+0x78/0xc0
[   10.392386]  bus_iommu_probe+0x48/0x300
[   10.392412]  ? kmem_cache_alloc_trace+0x10f/0x2a0
[   10.392438]  bus_set_iommu+0x88/0xe0
[   10.392459]  ipu_mmu_probe+0x3c/0xd0 [intel_ipu4p_mmu]
[   10.392489]  ipu_bus_probe+0x81/0x270 [intel_ipu4p]
[   10.392518]  really_probe+0x205/0x460
[   10.392539]  driver_probe_device+0xe1/0x150
[   10.392562]  device_driver_attach+0xa1/0xb0
[   10.392585]  __driver_attach+0x8a/0x150
[   10.392606]  ? device_driver_attach+0xb0/0xb0
[   10.392631]  ? device_driver_attach+0xb0/0xb0
[   10.392656]  bus_for_each_dev+0x78/0xc0
[   10.392676]  bus_add_driver+0x12b/0x1e0
[   10.392699]  driver_register+0x8f/0xe0
[   10.392720]  ? 0xffffffffc0c91000
[   10.392741]  do_one_initcall+0x44/0x200
[   10.392761]  ? do_init_module+0x23/0x250
[   10.392783]  ? kmem_cache_alloc_trace+0x10f/0x2a0
[   10.392810]  do_init_module+0x5c/0x250
[   10.392830]  __do_sys_init_module+0x129/0x1a0
[   10.392857]  do_syscall_64+0x33/0x40
[   10.392875]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   10.392901] RIP: 0033:0x7f05284e532e

I suspect these errors are related to some updates I had to make the some iommu-related code to get the kernel to compile.

Anyways, while I have a fairly solid grasp of C, I'm not really confident in my knowledge of kernel code and am somewhat lost at this point. Was wondering if anyone with the requisite experience would be willing to review my fork so we can get this working and perhaps even upstreamed if possible.

kbingham commented 2 years ago

@konturn Great - thanks for looking into this. A knowledge of C code is all you need, the rest will fall into place. Find me on IRC as kbingham (libera or OFTC) or Matrix as @kbingham:matrix.org if you need a direct line.

The null-dereference is quite likely stopping the load of the modules indeed,so then the script will not be able to find any video devices as the drivers don't fully load.

That's certainly the next steps to fix.

Have you ever interacted with a linux mailing list before? The best place to get support on this is the linux-media mailing list, where there are developers actively trying to get the IPU2 to work as well.

grrodre commented 2 years ago

Is there some work in this driver/port?

kbingham commented 2 years ago

The tasks involved require several to many months worth of development. I believe we're still in the stage of 'waiting for someone to either do the work or sponsor it` Happy to provide guidance if someone wants to try - but I think the comments I've given above somewhat already summarise the work involved.

Kleist commented 5 months ago

Intel is working on upstreaming a driver for the IPU6 on the linux-media mailing list, and I've done some of the work to port this to IPU4 (PCI 5a88). It does currently not support IPU4P (PCI 8a19) which this thread is about.

See https://lore.kernel.org/all/e136389011517dbc65b30f6bf0b1a9c49ab4e599.camel@gmail.com/ for more info, which also links to my github: https://github.com/Kleist/linux/tree/kleist-v6.6-ipu4-hacks-1 where the code is available. Please be aware that the current code is not directly applicable, you would need to do some work to 1) make it work on IPU4P and 2) remove my ipu-bridge hacks.

It is based on this IPU6 patch series from Intel, which is currently in v3: https://lore.kernel.org/all/20240111065531.2418836-1-bingbu.cao@intel.com/ You should be able to see future versions with this search: https://lore.kernel.org/all/?q=s%3Aintel%2Fipu6

lkraav commented 5 months ago

Intel is working on upstreaming a driver for the IPU6 on the linux-media mailing list, and I've done some of the work to port this to IPU4 (PCI 5a88). It does currently not support IPU4P (PCI 8a19) which this thread is about.

Wow, this is some superhero :superhero: level stuff :muscle: Working webcam would certainly extend the lifespan of this otherwise fine 32G/1TB workload beast for some extra years!