Camera shows in lsusb but no video device: check the USB class

A camera that enumerates in lsusb but never shows up as /dev/video* looks like a driver problem, and the usual reaction is reinstalling modules. Read one field first: bInterfaceClass from lsusb -v. It settles the case in two minutes. Class 255 (vendor-specific) means no kernel video driver will ever bind — the device speaks a private protocol and the vendor SDK is the intended acquisition path, which is the designed behaviour of machine-vision USB3 cameras. Class 14 (video) means uvcvideo should claim the device, so the fault sits in the module, the node numbering, the permissions or the container. This page gives the test for each branch, the likely faults in probability order, the bandwidth arithmetic that predicts a stalled stream, and the buying decision that keeps the problem off your bench.

The verdict in one field: bInterfaceClass

lsusb only proves enumeration: power is present and the host has read the descriptors. A /dev/video* node appears only after a kernel driver claims an interface, and for modern cameras that driver is uvcvideo, which matches USB Video Class devices. The question is never 'is the camera detected?' — it is 'which class does each interface declare?'

lsusb
lsusb -v | grep -E "idVendor|idProduct|bInterfaceClass"

Find your device's idVendor and idProduct pair, then read the bInterfaceClass lines that follow. lsusb prints the codes in decimal:

Read every interface, not just the first: a camera can pair a vendor control interface with a UVC streaming interface, and the node then appears anyway. If every interface reads 255, no node can ever appear — install the vendor SDK and stop troubleshooting the kernel. If the device is not even listed by lsusb, the fault sits lower in the stack: work the USB link checks after a cable swap first.

Class 255: nothing is broken — the SDK is the driver

Machine-vision cameras follow the USB3 Vision standard, and that standard deliberately runs camera control over a vendor-specific class interface. Pixels cross bulk endpoints; a userspace library — the vendor SDK or its GenICam GenTL producer — does the work a kernel driver would otherwise do: discovery, streaming, exposure and trigger control. A dmesg line reading New USB device found with no driver claim afterwards is the expected signature, not a fault, and lsusb may well name a bridge chip and its silicon vendor instead of a camera maker.

The fix is an install, not a compile. Take the vendor's host library or GenTL producer from the manufacturer or its distributor, load it from your acquisition code, and the camera streams. A GigE Vision camera behaves the same one layer up: it never produces a video node either, because frames arrive as Ethernet packets.

Engineers also trip over product variants. The same sensor family can ship as an evaluation kit, whose bridge controller enumerates as a generic vendor device, and as a UVC kit, whose firmware declares class 14 and appears as /dev/video* with no configuration — the out-of-the-box path the UVC camera with no config file walkthrough shows. The evaluation kit needs its own host software instead. If lsusb lists the camera but that SDK still finds nothing, hand the case to the vision SDK detection checks.

Worked example: can the link even carry the frames?

lsusb -t prints the device tree with the negotiated speed: 5000M for a healthy USB 3 link, 480M for a camera that fell back to high speed. When a node exists but frames stall or the frame rate collapses, that line is the first suspect, and the arithmetic says why. Work it for the 12 MP USB3 LS-CMR-0166 at its full 30 fps rate:

Reading it back: the LS-CMR-0166 streams 4000 × 3000 at 30 fps, so at 8 bits per pixel a frame is 12 MB and 30 fps demands 360 MB/s — 2.9 Gbit/s. A USB 3.0 link signals at 5 Gbit/s and carries roughly 4 Gbit/s of payload after 8b/10b overhead, leaving about 1.1 Gbit/s spare. On a 480 Mbit/s USB 2 link, practical bulk throughput sits near 35 MB/s, a tenth of the demand, so the same frames arrive at roughly 3 fps or not at all. If lsusb -t prints 480M under a camera that should deliver 30 fps, that arithmetic — not a missing driver — explains the stall. The lsusb -t speed fallback walkthrough traces what drags a link down and how to recover SuperSpeed.

Higher bit depths scale the demand linearly: 10-bit mono lifts it to 450 MB/s (3.6 Gbit/s), which still fits the payload, while 16-bit containers double it to 720 MB/s and force a lower frame rate. Embedded ARM hosts add controller-side causes of their own, and the USB3 camera fallback troubleshooting for embedded boards page works through those.

Class 14 and still no node: four faults, in probability order

1. The driver never loaded. lsmod | grep uvcvideo returns nothing. Load it with sudo modprobe uvcvideo; dmesg should then log a uvcvideo line claiming the device. On trimmed kernels — most embedded builds — the module may not exist at all: zgrep CONFIG_USB_VIDEO_CLASS /proc/config.gz shows whether the driver was ever compiled in. If the option is unset, no amount of replugging helps until the kernel ships it.
2. You are opening the wrong node number. One UVC camera can own two nodes, an image node and a metadata node, so the camera may be /dev/video2, not /dev/video0. Ask v4l2-ctl --list-devices which node is which instead of opening by number.
3. The node exists but only root can open it. A fresh node inherits restrictive permissions; your user needs the video group or a udev rule. The Linux camera device permissions checks walk that diagnosis node by node.
4. The node lives on the host, not in the container. Containers see only what you pass in. The Docker V4L2 media node walkthrough lists the nodes and cgroup rules to forward.

A fifth case has its own article: the node is correct yet the program still opens nothing, which is a capture-path question. The choosing the right capture path guide sorts V4L2, libusb and vendor-library routes.

Decide the acquisition path before you order

The whole diagnosis collapses into one buying decision: which side of the class line does your software live on?

If your pipeline only speaks V4L2, a UVC camera is the honest answer — accept the mostly automatic exposure and consumer-grade timing. If the inspection needs trigger inputs or shutter determinism, order USB3 Vision and budget the vendor SDK install on the host. The GigE Vision camera on an RT controller article shows the same GenTL thinking for the network side.

If the second row is your case, the area scan cameras category filters by interface, shutter and sensor format, and board-level cameras give the same electronics without a housing for custom carriers. Three parts that make the SDK path concrete:

LS-CMR-0166 covers the detail work at 12 MP over USB 3, MV-CH120-11UC adds a global shutter behind a C-mount for moving parts, and MV-CB060-10UM-B is the bare-board build for embedding in your own carrier. When the part needs more pixels, the MV-CS200-10UM carries a 20 MP IMX183 sensor behind a C-mount on USB 3.0.

The camera finder filters by interface and shutter in one pass, and the camera step of the configurator pairs the camera with a matching lens and light.

The full check sequence

Run the steps in order; the first one that answers the question ends the session.

1. Unplug the camera, run ls /dev/video*, plug it back in, run it again. New numbers appear? The camera works — name the capture node with v4l2-ctl --list-devices and stop here.
2. lsusb. Nothing listed? The fault is power, cable or port — start from the cable-swap checklist linked earlier.
3. sudo dmesg | tail -20 straight after plugging. New USB device found proves enumeration; no driver line after it proves no interface was claimed.
4. lsusb -v | grep -i binterfaceclass. Every interface at 255: install the vendor SDK, case closed. A 14 present: continue.
5. lsusb -t: read the negotiated speed and the Driver= label — uvcvideo bound, or nothing.
6. lsmod | grep uvcvideo, then sudo modprobe uvcvideo if it is missing; on embedded kernels check CONFIG_USB_VIDEO_CLASS in the build config.
7. Class 14, module loaded, still no node? Check group membership (video) and, inside a container, whether the nodes were passed through.
8. Class 255 confirmed? Install the vendor library from the manufacturer or its distributor and acquire through it. /dev/video* will never appear, and that is the correct behaviour.

When the standard advice is wrong

Two pieces of common advice waste hours here. Reinstalling v4l-utils changes nothing: those packages ship tools that read video nodes, not drivers that create them. And recompiling the kernel for UVC support is the wrong spend when every interface reads 255 — no kernel option creates a node for a vendor-specific interface, so the effort belongs in the vendor library install. The preventive habit is the table in the buying section: agree on the acquisition API first, and a class-255 camera never reaches a V4L2-only pipeline. More host-side integration notes, from device nodes to containers, sit on the systems topic page.