Due to current situation with COVID-19 many people have to work from home and participate in video conferences. If you happen to need a new PC camera now like me you will find out that the prices of new PC cameras that used to cost $50 went up drastically. So I thought about using for this purpose one of the "still" cheap actioncams which could also run in PC camera mode.

Here is a cheap and silly workaround for 4K action cameras with idVendor=1f3a (USB ID 1f3a:10** Onda (unverified) Android) to avoid automatic USB disconnect and switch to storage when in camera mode.
If I am not mistaken, the following cameras can be used:
Renkforce Action Cam RF-AC-4K
Allwinner V3/s + IMX179/s, OV4689 and GC2023 action cameras
Pruveeo DV200 4K
Andoer AN100 4K

I have tested it on Slackware but it should work on any Linux distro

# as root modify the uvcvideo module options

vi /etc/modprobe.d/uvcvideo.conf
options uvcvideo quirks=0x80

# reboot

# when PC is up turn your camera on but do not activate camera mode yet

# Run as user cat command on video devices in an infinite loop to make the camera believe that the video device is constantly accessed which avoids disconnects
while :; do cat /dev/video*; sleep 1; done

# activate the camera mode now

# In another terminal window as user verify the video output
mplayer tv:// -tv driver=v4l2:width=640:height=480:device=/dev/video0 -fps 60

# as long as the "while do" loop is running the Camera should stay in the camera mode and the video device /dev/video* should be available at this time to other applications like Microsoft Teams or Skype

Hi,
I tried the steps above and all works fine but a little bit too dark under Ubuntu 20.04 Beta (Focal Fossa).
After testing I closed all terminal windows to end the "while do" loop.
But afterwards my USB sticks, card readers and HDDs didn't automount after plug in.
"lsusb" shows me they are recognized but I can't get them mounted.

How can I fix it?

Hi DerDonYogi

Thanks for trying the workaround. I have tested it on a system without any other USB devices attached except for the camera. It seems that the step with android.rules is not required at all in order to keep the camera in its camera mode. I have updated instructions above. You can comment out the three lines like below:

vi /etc/udev/rules.d/51-android.rules
#KERNELS=="[1-9]*-[0-9]*", SUBSYSTEMS=="usb", DRIVERS=="usb", ATTRS{idVendor}!="1f3a", ENV{IF_STORAGE_REMOVE_ME}="1"
#KERNELS=="[1-9]*-[0-9]*", SUBSYSTEMS=="usb", DRIVERS=="usb", ATTRS{idVendor}=="1f3a", ATTRS{idProduct}=="1002", ENV{IF_STORAGE_REMOVE_ME}="1"
#ENV{IF_STORAGE_REMOVE_ME}=="1", DRIVERS=="usb-storage", DRIVER=="sd", RUN+="/bin/sh -c 'echo -n %k >/sys%p/driver/unbind'"

then reboot your computer and you should be able to use your USB devices together with camera.

If the picture of you camera appears to be dark then you can adjust the Exposure mode in your camera settings to +3. Otherwise you need more light.

1 members found this post helpful.

Hi tarnow,
great job.
I forgot to name my cam. It's a Renkforce Action Cam RF-AC-4K.
Your new instructions are working fine after deleting the "51-android.rules" file. I can use it with Zoom but the cam won't be recognized for example by the "Cheese" app.
Is the cam recording with sound in webcam mode? Zoom shows no mic.
USB sticks working fine too. :-)

Thanx for your work.

Hey DerDonYogi,
I am happy this is working for you.
I am not sure if the video format produced by these cameras can be properly recognized by programs like guvcview or cheese.
On my system guvcview shows the image but it is all green. I think my video libraries need to be updated.
As for the sound I have not seen it reporting any additional audio device on USB port. Would be nice to know if the mic is recognized by windows.

I have a similar camera connected to Jetson Nano with Ubuntu 20. The hwinfo output is below. I tried Tarnow's method, but the file "uvcvideo.conf" did not exist, so I created a new file with the single line "options uvcvideo quirks=0x80". I feel like I missed something, if so, please help. Thanks!


25: USB 00.1: 0000 Unclassified device
[Created at usb.122]
Unique ID: 9DX5.voo7w9mitY9
Parent ID: cLrx.xvTGa+XkbXF
SysFS ID: /devices/70090000.xusb/usb1/1-2/1-2.3/1-2.3:1.1
SysFS BusID: 1-2.3:1.1
Hardware Class: unknown
Model: "Onda (unverified) Android"
Hotplug: USB
Vendor: usb 0x1f3a "Onda (unverified)"
Device: usb 0x1002 "Android"
Revision: "2.33"
Serial ID: "20080411"
Speed: 480 Mbps
Module Alias: "usb:v1F3Ap1002d0233dc00dsc00dp00icFFisc42ip01in01"
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #24 (Hub)

Hi Olebon

Thanks for using my instructions. Have you first tried the loop command "while :; do cat /dev/video*; sleep 1; done" and then activate the web camera mode?
Please make sure the loop command is still running (in another terminal window) before activating the camera mode.
Alternatively you can try to setup your camera in OBS Studio. OBS Studio will also keep your video device opened as long as your camera is connected.
I do not have this kind of camera anymore and it is possible that my original post from the last year is already obsolete.

Please correct me if I am wrong, but the loop is not really a command. It simply expects that the system will identify the camera and create a handle /dev/video* after some delay, so it just keeps polling the /dev directory to check if the file is created. Unfortunately in my case no such handle were created at all. I tried to troubleshoot this issue further and found that this camera driver is handled by some uvcvideo software https://help.ubuntu.com/community/UVC . I tried to install it without success (compilation fails without clear diagnostic), later it turned out that this package is supposed to be part of kernel since linux 2.6.

The /dev/video* handle is created by the uvcvideo driver and the loop command just makes sure this video device is not automatically removed from the system after it was created by constantly polling for its content. The automatic /dev/video* removal will usually happen after 1-2 sec. after it was created so it is better to start the while loop command before turning on the camera.
I wonder if your uvcvideo driver is being loaded. You can check it with "lsmod | grep uvcvideo". If not try:
"modprobe uvcvideo quirks=128" or just "modprobe uvcvideo"

Hi Tarnow
Thanks for the hint, I've been looking for a solution to the USB ID 1f3a:1004 problem but couldn't find it for the past 2 weeks, and using " while :; do cat /dev/video*; sleep 1; done " it worked on my raspiberry pi, My action cam is detected but the FPS is very slow, only 6-9 FPS.
Is it because of the while? how to increase the FPS?
I want to try to edit the rules in "/etc/udev/rules.d/51-android.rules" but this rules file doesn't exist on raspberry pi , in the rules.d folder there is only 99-com.rules and I deleted it but my camera still unreadable without while.
Do you have a solution to change the rules on the raspberry pi so you don't need to use while ??
thank you

Hello Abdullahm181,

Thanks for using my instructions. You do not need udev rules to get the camera connected and keep it in the camera mode assuming your user is in the video group. The while loop is the quickest way to poll for the camera to prevent it from being disconnected. I think this is similar to what windows driver does. You could write this loop in a shell script and start it before connecting your camera. I believe you have checked the camera settings to make sure it can output more than 10 FPS.
Here is what you can try on your RPI to get more FPS:
- for RPI4 make sure you have at least 512 MB set for your gpu_mem in /boot/config.txt (gpu_mem=512). Changes in /boot/config.txt requires restart of your RPI.
- it is possible that some other USB devices connected to your Pi are using most of the bandwidth preventing your camera to utilize its full speed. You can try to disconnect all the USB devices except for the camera and see if it helps.
- could be that some applications are using most of the CPU/RAM preventing camera to work as it should. Try to close all the applications except for the ones needed by the camera.
If this does not help then you could consider some other system with more resources.

Hope this helps