Your depth camera is right there in lsusb, dmesg shows the uvcvideo driver binding it, and the camera's own SDK still answers "no device connected". The USB link is proven and the class driver is loaded, so reinstalling changes nothing. On a laptop, the usual cause is not software: the integrated webcam is a second UVC camera, it takes the first /dev/video nodes, and the depth camera's node block lands where the SDK does not look. This guide runs the diagnosis in the order that pays off — prove the link, count the nodes, then disable the webcam or pin the camera by serial number — and closes with the rarer causes: USB 2.0 fallback, node permissions, containers and SDK-firmware mismatch. You need a shell and about ten minutes.
What the log already proves
Start with what the log settles. When lsusb lists the camera and the entry disappears the moment you unplug it, power, cable and the SuperSpeed link all work. dmesg then reports a new SuperSpeed USB device and uvcvideo finding a UVC 1.10 device — twice, because the camera exposes more than one streaming interface. The driver is bound; stop reinstalling it.
The same log carries "Unknown video format" warnings for the camera's private depth formats, and possibly a warning about an unknown pixelformat such as 0x2036315a. A stock kernel does not know a depth camera's depth-specific formats; the SDK ships its own support for them. Those lines were present in the failure traced here and the camera still enumerated, so treat them as noise.
That pins the fault between the driver and the SDK: enumeration, the layer where a second UVC camera does its damage. The host-setup half of this symptom is covered in USB camera in lsusb but not detected by the vision SDK on Linux; the webcam half is below.
Why one camera owns several /dev/video nodes
One physical camera does not mean one node. A laptop with a single front camera has been documented listing /dev/video0, /dev/video1, /dev/video2 and /dev/video3 — four nodes for one camera. Kernels carrying the metadata patch add a second node that carries metadata about the first device's video, and a front module with color and infrared sensors exposes an interface per sensor.
A depth camera multiplies this: depth, infrared and color are separate streaming interfaces, so uvcvideo reports "Found UVC 1.10 device" once per interface and creates a node for each. Two bound interfaces plus their metadata nodes is a four-node footprint, and that is normal topology, not an error.
Node numbering is the weak point. Applications use the /dev/video numbering to decide which camera they open, and that ordering is not persistent across boots. Add the integrated webcam and the depth camera's block starts at a different index on every boot. On top of that, libuvc — the cross-platform UVC access layer several SDKs build on — carries a known limitation where two USB cameras may fail to stream simultaneously. If your SDK runs in a container, also pass it every node the camera owns, not just the first: Camera in Docker: pass V4L2 media nodes, not just /dev/video0.
The 60-second node count
Run this before you change any driver:
- Close every camera application — viewers, SDK tools, video calls. A second application holding a camera can make its device nodes disappear, as camera device nodes disappear when a second application starts shows.
- Unplug the depth camera and run
ls /dev/video*. Note the count and the numbers: that block belongs to the webcam. Call it N_unplugged. - Plug the camera into a rear root port and wait for dmesg to settle.
- Run
ls /dev/video*again and call the count N_plugged. - The camera owns the difference — always the higher-numbered entries the kernel just added.
- Check
lsusb -t: the camera's entry must read 5000M. A reading of 480M means the link fell back to USB 2.0, which is its own failure — see USB3 camera negotiated USB2 speed: why lsusb -t shows 480M.
A difference of four is the typical footprint for a multi-interface depth camera on a current kernel.
Worked example: one laptop, one depth camera, eight nodes
Inputs, each from the failure traced here:
- Host: a laptop with an integrated UVC webcam.
- Camera: a USB 3.0 depth camera that enumerates as a SuperSpeed device at 8086:0aa5, with uvcvideo finding its UVC 1.10 interfaces twice in dmesg — two streaming interfaces.
- Webcam block: /dev/video0 through /dev/video3, the four-node listing a single-camera laptop shows.
- SDK symptom: "no device connected" while lsusb holds the camera and loses it on unplug.
Rule: the plug/unplug difference is the camera's own node block.
Arithmetic:
- Interfaces bound by uvcvideo: 2.
- Nodes per interface on a kernel with the metadata patch: 2 (capture plus metadata).
- Camera nodes: 2 × 2 = 4.
- Webcam nodes: 4 (/dev/video0 to /dev/video3).
- Total plugged: 4 + 4 = 8, so the camera owns /dev/video4 through /dev/video7.
- Node count check: N_plugged - N_unplugged = 8 - 4 = 4. The two methods agree.
Decision: the hardware is fully present — SuperSpeed link, driver bound twice, four camera nodes — so the failure is selection. An SDK that starts at the bottom of the node list meets the webcam's block first. Disable the webcam (next section) or pin the camera by serial number. On this machine, disabling the integrated webcam was the whole fix: the SDK listed the camera immediately afterwards.
Fix A: take the integrated webcam out of the enumeration
The cleanest laptop fix is firmware: most laptops expose an integrated-camera on/off setting in setup. Switch the webcam off and it never enumerates; the depth camera takes the low nodes and the SDK finds it. That is what resolved the case traced here.
If the firmware offers no switch, unbind uvcvideo from the webcam's USB device only. The kernel supports per-device driver binding, so the module stays loaded, the depth camera keeps its nodes, and the webcam loses its own.
Confirm the fix by counting again: the node list should now hold only the camera's four entries, and the SDK should list its depth, infrared and color streams.
Fix B: keep both cameras and pin the depth camera
Keeping both cameras is the right answer when the webcam must stay — conference software on the same host, for example. Select the depth camera by serial number inside the SDK, the standard method whenever more than one depth camera shares a host: multiple depth cameras on one host: select each by serial number.
One limit: if dmesg shows SerialNumber=0 for the camera, there is no USB serial string to match, so serial-keyed device rules cannot separate the two cameras. The fallbacks are a fixed physical root port — same port every boot — and a fresh node count after each replug to identify the camera's block. Never hardcode /dev/video4; the ordering is not persistent across boots.
Selection only helps if the nodes open. A correctly selected node still fails without device permissions, so run the SDK from the account that owns the session and work through Linux camera device permissions: video and media node checks.
The other causes, in order of probability
With the webcam ruled in or out, the remaining causes of "no device connected" rank like this:
| What you see | Cause | Ten-second test | Fix |
|---|---|---|---|
| Camera in lsusb, SDK empty, laptop webcam present | Webcam owns the low node block | Plug and unplug node count | Disable webcam or select by serial |
| lsusb -t reads 480M at the camera | USB 2.0 fallback | Read the speed column | Rear root port, USB 3.0 cable |
| Nodes exist, SDK cannot open them | Device node permissions | Run the SDK from the owning account | Fix permission on video and media nodes |
| Camera present, then gone | Another process holds it | Close apps, watch dmesg | One owner at a time |
| SDK in a container finds nothing | Container got one node, not the block | Compare node lists inside and outside | Pass every node the camera owns |
| Enumeration fine, device creation fails | SDK and camera firmware mismatch | Compare the two version strings | Align SDK and firmware |
One more trap: userspace camera servers that install their own UVC driver replace the kernel driver's nodes. dmesg shows which driver bound each camera; two drivers claiming one camera delete each other's nodes.
Cables and ports that fail the same way
Depth streams need SuperSpeed bandwidth, so a USB 2.0 fallback often surfaces as the same "no device" error rather than as a slow image. After lsusb -t confirms 5000M, remove the remaining electrical variables at bring-up: rear root port, no hub, and a known USB 3.0 cable in place of whatever shipped in the box. The camera data cables category covers every length class from 1-2 m to over 20 m.
The LS-CBL-0219 is a 3 m USB3.0 camera cable in high-flex drag-chain form; on a bench it simply removes the cable as a variable.
Camera data, power and I/O cables
401 models · from $22.00When the webcam is not the answer
On a desktop with no integrated camera the same symptom re-ranks: USB 2.0 fallback first, permissions second, then the driver itself — on some hosts the UVC driver is built in rather than loaded as a module, which changes how you check it: uvcvideo module not loaded: check for a built-in driver. When enumeration succeeds but device creation fails, compare the SDK version against the camera firmware; a header and firmware mismatch breaks device creation before a frame is ever requested: 3D camera header version mismatch: fix firmware and SDK alignment. A camera that enumerates but will not open for a second user points at a stale device lock, not the webcam: stale /dev/shm device lock when a second user opens the camera.
For a fixed inspection station, remove the whole failure class: choose a host with no integrated camera. Industrial mini PCs carry none, so the low node block always belongs to your depth camera. A depth / ToF camera such as the MV-DT01WMU then enumerates into an empty node map.
- Type
- Depth / ToF camera
Checklist before you reinstall anything
Work down this list before touching a driver package again:
- lsusb entry appears when plugged and disappears when unplugged — link proven; drivers are not the problem.
- dmesg shows uvcvideo finding the UVC 1.10 device once per interface — driver bound.
- Node count difference equals the camera's block; four nodes is typical for this class.
- lsusb -t reads 5000M at the camera — not 480M.
- Integrated webcam disabled in firmware, or camera pinned by serial or a fixed root port.
- Every camera application closed; SDK run from the account owning the session.
- SDK version aligned with camera firmware.
Next step
Keep the working combination once the SDK lists the camera: fixed root port, known cable, webcam off or camera selected by serial. For a new station, start from the 3D sensors category or the camera finder and build around a host with no camera of its own. If the node count shows your camera's block and the SDK still refuses it, send the two node listings and the dmesg output to our support team — free expert support comes with every order.
Questions
Why does one camera create four /dev/video nodes?
A UVC camera gets a node per streaming interface, and kernels carrying the metadata patch add a second node that carries metadata about the first device's video. A laptop front module with color and infrared sensors therefore lists /dev/video0 through /dev/video3 from a single physical camera. Four nodes for one camera is normal topology, not four devices and not an error. Which block belongs to the depth camera is settled by the plug and unplug count, not by the node numbers.
Should I blacklist the uvcvideo module to stop the webcam?
No. The depth camera is itself a UVC device — in the failure traced here, uvcvideo is the driver binding it. Blacklisting or unloading the module removes both cameras and turns a selection problem into a no-driver problem. Unbind the driver from the webcam's USB device only, or switch the webcam off in firmware setup; the module then stays loaded and the depth camera keeps its nodes.
My depth camera shows SerialNumber=0 in dmesg. Can I still pin it by serial?
Not at the USB level: with SerialNumber=0 there is no USB serial string to match, so serial-keyed device rules cannot tell the two cameras apart. Pin the camera to one physical root port instead and re-run the node count after each replug to identify its block. Selecting the camera inside its own SDK, which names its cameras by its own identifiers, also works and survives reboots.
Does the integrated webcam conflict happen on Windows too?
Rarely. Windows names each camera device individually, so a second camera does not renumber the first out from under an SDK the way Linux /dev/video numbering can. On Windows, a camera present in Device Manager but missing in the SDK points instead at driver binding or a USB 2.0 fallback. The node-count diagnosis in this guide is the Linux path.
Do the 'Unknown video format' lines in dmesg matter?
No. A stock kernel does not know a depth camera's private pixel formats, so uvcvideo logs unknown-format warnings while still binding every interface. The failure traced here showed exactly those lines, and the camera enumerated and worked once the webcam conflict was cleared. The lines that matter are the ones reporting a UVC 1.10 device found and the driver bound to each interface.