Trouble with an external USB camera (Logitech C270, 720p)

Hi everyone,
I’ve been having trouble with an external USB camera (Logitech C270, 720p) on my Snapmaker U1 running paxx12 Extended Firmware v1.4.1. The camera would show up correctly in v4l2-ctl --list-devices and the V4L2 Controls panel, but the video stream kept failing with VIDIOC_DQBUF: No such device, and dmesg showed constant USB resets (usb 3-1.3: reset high-speed USB device…) roughly every 13-14 seconds.
After digging through SSH, I found that stopping the control-v4l2.py process for the USB device (/dev/video18) immediately fixed the stream — kadri started flowing normally as soon as that process wasn’t polling the camera. So it looks like my particular camera doesn’t handle the V4L2 control-polling well and resets under that load.
Since my C270 unit is clearly getting old, I’m planning to retire it and buy a new webcam instead of fighting this. Before I do:

Has anyone had reliable long-term success with a specific webcam model on this firmware (ideally small and cheap)?
Is the C920/C920S known to behave better with the control-v4l2 polling than the C270?
Is this a known issue with certain older UVC chipsets, or is there a fix/workaround planned for the control-v4l2 service itself?

Must be UVC-compatible (almost all modern brands are, but avoid completely unknown no-names from AliExpress without clear specifications - that’s where you often find “crappy” UVC implementations that are just as buggy as your old camera).
And yet, due to the limited budget, I’m asking for advice on a compatible cheap 1080 p camera from AliExpress

Happy to share full SSH logs if that’s useful for debugging on the firmware side. Thanks!

Here’s a summary of the steps to get it running. Maybe someone will find it interesting. Personally, I don’t understand any of this.

Restoring a USB camera (Logitech C270) on Snapmaker U1 (paxx12)
Cause of the problem
The `control-v4l2.py` process, which handles the “V4L2 Controls” panel for the USB camera, periodically polls the old Logitech C270 camera. The camera can’t handle these requests and resets at the USB level (~every 13 seconds), which causes:
the camera’s LED to flash,
the video not to appear in the Preview (endless spinner).
The problem recurs after every printer reboot because control-v4l2.py for the USB camera restarts automatically.
Quick fix (must be repeated after every reboot)

  1. Connect via SSH
    Open PowerShell (Start → powershell) and run:

ssh root@192.168.1.9

Password: snapmaker
2. Find the control-v4l2.py process for the USB camera

ps aux | grep control-v4l2

Find the line with --device /dev/video18 (this is the one for the USB camera; do not confuse it with /dev/v4l-subdev2—that’s the built-in camera).
3. Stop this process

kill

(replace with the PID from the previous step)
4. Verify that the camera is free

lsof /dev/video18

It should be empty (no process is holding the device).
5. Verify that the USB resets have stopped

dmesg | tail -5

Wait 30–40 seconds, then repeat the command—no new lines saying “reset high-speed USB device” should appear.
6. Start video capture manually in the background (it will continue even if the SSH session is closed)

nohup /usr/local/bin/fake-service --retry 3 /usr/local/bin/capture-v4l2-jpeg-mpp --device /dev/video18 --jpeg-sock /tmp/capture-usb-jpeg.sock --mjpeg-sock /tmp/capture-usb-mjpeg.sock --h264-sock /tmp/capture-usb-h264.sock > /tmp/usb-capture.log 2>&1 &

  1. Check the result
    Open the V4L2 Controls / Preview page in your browser and make sure the image appears and remains stable.
    Important
    Do not open the Exposure/White Balance advanced settings section for the USB camera in the web interface—this restarts control-v4l2.py and will once again cause the camera to enter a reset loop.
    This is a temporary solution—it resets after every printer reboot, so you’ll have to repeat steps 1–6 each time.
    Long-term solution
    The camera (Logitech C270) is considered obsolete for this task. We plan to replace it with a newer model (such as the Logitech C920/C920S), which will likely handle the control-v4l2.py polling better.