Module no longer loading with correct parameters

I use the Droidcam software to use my android phone as a webcam. I have been using it in HD mode just fine for a few years now. However, for some reason, recently it’s stopped loading the module with the correct resolution parameters. It may or may not have coincided with one of their new releases. But I’ve uninstalled and downgraded to the previous version that was working and it still has the same problem (SD resolution).

I’ve reached out to the software developer, but it’s not obvious it’s anything to do with their code since even the previous version which was working fine is now no longer working. So I’m wondering if a recent OpenSuse update (usual Leap 15.5 update repos) has changed some way module parameters are loaded at boot.

Module parameters are passed via this file:

❯ cat /etc/modprobe.d/droidcam.conf 
options snd-aloop index=3
options v4l2loopback_dc width=1920 height=1080

If I remove the module and re-insert it manually using:
sudo insmod /lib/modules/uname -r/kernel/drivers/media/video/v4l2loopback-dc.ko width=1920 height=1080 then it works OK again. Until reboot, when it returns to SD resolution.

Any suggestions for troubleshooting this further please?

I’m using this on Tumbleweed and haven’t found it to be an issue. Something that I would check is that v4l2loopback_dc is mapped to the correct /dev/video* device node. If v4l2loopback is loading, Droidcam can use that as well, and that will load at a lower resolution.

And is this option ignored too?

Does using

modprobe v4l2loopback-dc

pick up these parameters?

This line is most certainly wrong.

The module could be loaded in initrd already. Check initrd content. Or the module may be explicitly loaded by some software.

Ah, that’s an interesting thought. How would I check the mapping, and then correct it if it’s wrong?

If you’re using the droidcam-cli program, try running it pointing to /dev/video1 instead of /dev/video0 (assuming /dev/video1 exists - you can ls /dev/video* to see if that’s the case.

It’s similar if you’re using the GUI application, but testing with the CLI might be simpler as a test.

Thanks. I’ve tried that, and even tried passing the width/height via the cli, but it still comes up in SD.

This is the status of the module parameters after boot, and then after a manual reload of the module:

❯ for i in /sys/module/v4l2loopback_dc/parameters/*; do ls $i && cat $i; done
/sys/module/v4l2loopback_dc/parameters/height
480
/sys/module/v4l2loopback_dc/parameters/video_nr
-1
/sys/module/v4l2loopback_dc/parameters/width
640

❯ sudo modprobe -rv v4l2loopback-dc 
rmmod v4l2loopback_dc

❯ sudo modprobe -v v4l2loopback-dc 
insmod /lib/modules/5.14.21-150500.55.52-default/kernel/drivers/media/video/v4l2loopback-dc.ko width=1920 height=1080 
 
❯ for i in /sys/module/v4l2loopback_dc/parameters/*; do ls $i && cat $i; done
/sys/module/v4l2loopback_dc/parameters/height
1080
/sys/module/v4l2loopback_dc/parameters/video_nr
-1
/sys/module/v4l2loopback_dc/parameters/width
1920

So modprobe is happily picking up the right parameters when manually reloading the module, but not on boot. Any thoughts?

Unsure about this. Does this indicate that it’s not?

❯ cat /sys/module/snd_aloop/parameters/index 
3,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1

Yes, it does - you can see in my previous post.

Oh, the backticks didn’t come through due to the markup!

Thanks for the help. How do I do this please?

What is the output of lsmod | grep v4l2loopback?

Are you installing from source? If so, how are you running the installation - are you manually building or using the install-video script?

sudo lsinitrd /boot/initrd-$(uname -r)
❯ sudo lsmod | grep v4l2loopback
v4l2loopback_dc        28672  0
v4l2loopback           45056  0
videodev              274432  2 v4l2loopback_dc,v4l2loopback

I’ve been using the install-video script, and doing so quite happily for several years.

❯ sudo lsinitrd /boot/initrd-$(uname -r) | grep -E 'v4l2|droid'
-rw-r--r--   1 root     root          118 Mar 20 09:33 etc/modprobe.d/droidcam.conf
-rw-r--r--   1 root     root           35 Nov 29  2022 etc/modules-load.d/droidcam.conf
-rw-r--r--   1 root     root           70 May 22  2023 lib/modprobe.d/98-v4l2loopback.conf
-rw-r--r--   1 root     root        83083 May 22  2023 lib/modules/5.14.21-150500.53-default/updates/v4l2loopback.ko
-rw-r--r--   1 root     root        25294 Mar  6 10:32 lib/modules/5.14.21-150500.55.52-default/kernel/drivers/media/common/videobuf2/videobuf2-v4l2.ko.zst
drwxr-xr-x   1 root     root            0 Mar 20 09:33 lib/modules/5.14.21-150500.55.52-default/kernel/drivers/media/v4l2-core
-rw-r--r--   1 root     root       152095 Mar  6 10:32 lib/modules/5.14.21-150500.55.52-default/kernel/drivers/media/v4l2-core/videodev.ko.zst
-rw-r--r--   1 root     root        59376 Mar 20 09:33 lib/modules/5.14.21-150500.55.52-default/kernel/drivers/media/video/v4l2loopback-dc.ko
lrwxrwxrwx   1 root     root           58 Mar 20 09:33 lib/modules/5.14.21-150500.55.52-default/weak-updates/updates/v4l2loopback.ko -> ../../../5.14.21-150500.53-default/updates/v4l2loopback.ko
-rw-r--r--   1 root     root           13 May 22  2023 usr/lib/modules-load.d/v4l2loopback.conf

As a workaround (though I’d like to try and solve it properly if possible), could I just call a script after boot to remove and re-insert the module? Where would be best to put that script? I tried putting something in /etc/X11/xinit/xinitrc.d/but it didn’t seem to work.

Just noticed that the date of this initrd entry is different to the version in /etc:

❯ ls -al /etc/modprobe.d/droidcam.conf
-rw-r--r-- 1 root root 73 Apr 30 16:01 /etc/modprobe.d/droidcam.conf

So does the initrd need updating? Is that done by sudo dracut -f --regenerate-all ?

Ah! Running sudo dracut -f --regenerate-all has sorted it. Assuming that’s the right command, do you think I should run that every time I try and install a new version of droidcam?

Unless the parameters change in the file in /etc, you probably won’t need to unless you see the issue recur.

Glad to see that you sorted it - I’m going to keep this in mind for my installation as well. :slight_smile:

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.