UVC-compliant USB cameras on embedded Linux: skip the driver rebuild

You bolted an ARM board into the machine, flashed the vendor's Linux image, plugged in a USB camera — and lsusb lists the device while /dev/video* never appears. On your desktop the same camera just works. The difference is not the camera; it is which drivers the trimmed image decided to build. This guide is for engineers choosing a camera for an embedded Linux controller. You will be able to tell, before ordering, whether a camera runs with no kernel rebuild. One command checks the kernel's UVC class driver, the data sheet proves the camera speaks it, and a worked pixel budget sizes the sensor for the inspection. When machine-vision requirements outgrow UVC, the USB3 Vision cameras in the camera finder reach the same no-rebuild outcome through a user-space runtime. Both decisions, and the checks behind them, are below.

Which USB cameras work on an embedded Linux board with no kernel rebuild?

Two camera families run on a stock embedded Linux image with no kernel rebuild. UVC-compliant cameras are served by the kernel's USB Video Class driver as /dev/video* nodes. USB3 Vision cameras are driven by a user-space GenICam runtime that never touches the kernel.

Everything else means image work before the first frame: the older webcam families that depend on vendor-specific kernel modules, and raw sensor boards that need a platform driver written for the carrier. The decision rule is short. If the board keeps its stock image, buy a camera whose data sheet declares one of the two standards, and skip the kernel tree entirely. Machine-vision USB3 Vision parts sit in the area scan cameras category; modules meant to live inside your own housing sit in the board-level cameras category. If you start from the inspection rather than the board, the camera configurator walks sensor, resolution and interface in the order that matters.

How do you check that the UVC class driver is in the kernel?

Run zgrep USB_VIDEO_CLASS /proc/config.gz on the board. A line reading CONFIG_USB_VIDEO_CLASS=y means the class driver is compiled into the running kernel. =m means it ships as a loadable module. No line at all means no UVC support without a rebuild or a different image.

=y and =m are both good news: a built-in driver needs nothing further, and a module loads by itself when the first UVC device enumerates. The companion setting CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV only routes a camera's snapshot button into the input event layer; video works without it.

If /proc/config.gz is missing from the image, plug in a camera you know is UVC-compliant and read dmesg. The class driver announces the device and /dev/video0 appears within a second. lsusb lists vendor and product IDs either way, but enumeration alone proves nothing about drivers — that is the trap that makes a driverless camera look connected.

Once the node exists and your program still cannot open it, permissions are the usual cause; Linux camera device permissions: video and media node checks walks that case. If the driver is present and a compliant camera still fails to enumerate, the remaining causes live in the board itself — host-controller mode, device-tree settings, port power — and a checklist for UVC cameras not recognized on a Linux kernel works through them.

How do you prove a camera is UVC compliant before you buy it?

The camera's interface specification must state USB Video Class or UVC. Compliance is declared per device, and a plain USB 3.0 interface line says nothing about which protocol the camera speaks, because a USB3 Vision camera is electrically identical at the connector.

Current devices declare UVC 1.1 or UVC 1.5, and one built-in driver handles both, so either wording on a data sheet is a pass. Machine-vision USB cameras print USB3 Vision on the same line; treat that as the signal that the camera will never appear as /dev/video*, no matter what the headline says.

The cheapest proof costs a desktop: plug the camera into any Linux machine with the class driver, run dmesg, and watch the class claim the device with no vendor software installed. A camera that behaves that way on the desktop behaves that way on the board, because the same kernel code does the work. From there the stream itself needs no configuration — No config file needed: get a UVC camera streaming over USB shows the shortest path from plug to first frame.

Why do webcams that run on a desktop fail on an embedded board?

Desktop distributions compile a large family of legacy webcam drivers into their kernels, while a trimmed board image usually builds only the USB Video Class. An older camera that needs one of those vendor-specific modules enumerates in lsusb but never creates /dev/video*.

lsusb shows the device because enumeration is the host controller's job and happens with no driver at all. Binding a driver is a second step, and the trimmed image skips it for anything outside the UVC class. Note the vendor and product IDs lsusb prints, then watch dmesg on the board as the camera connects. If nothing claims those IDs, the module the camera needs is not in the image, and no application — Cheese, VLC, your own V4L2 code — can supply it from user space.

Two ways out. The fast one is commercial: order a UVC-compliant camera and the problem disappears. The slow one is building the missing driver into the image — a kernel tree for the board, a matching toolchain, and a rebuild for every image update. When the camera is UVC but your software still refuses to list it, the fault usually sits in the capture path rather than the driver; UVC camera not detected by software: choose the right capture path sorts the candidates.

Is a USB3 Vision camera the same thing as a UVC camera?

No: USB3 Vision is a machine-vision streaming standard, not the USB Video Class. A USB3 Vision camera never appears as /dev/video*; its pixels arrive through the vendor's GenICam runtime, which runs entirely in user space and therefore also needs no kernel rebuild.

For a production inspection — strobed light, encoder trigger, parts in motion — USB3 Vision is the stronger choice: GenICam exposes the features the video class never defines, and global shutter sensors are standard equipment there. For a presence check or a code read at a fixed station, a UVC device is simpler and just as correct.

The Linux-side work for USB3 Vision is user-space but not zero: the runtime needs usbfs memory headroom, and multi-camera hosts need file-limit changes. USB3 Vision cameras on Linux: usbfs and file limits that need tuning lists the settings.

Two catalog parts show the board-level end of this route. The LS-BCM-0003 pairs a global shutter with 120 fps over USB3 in a C-mount module. The MV-CB060-10UM-B ships as a bare board around an IMX178 sensor, for builds where housing height is tight. Choosing between bare modules and housed cameras is its own exercise; Board level camera selection for embedded vision machines covers it.

How many pixels does your inspection actually need?

Divide the field of view by the smallest feature you must see. Three pixels across a 0.1 mm defect in a 120 mm wide field needs 3600 pixels horizontally. A count a 5 MP class sensor cannot reach and a 4000 × 3000 sensor clears.

Three pixels across a feature is the working minimum for reliable detection; five is the target once you measure rather than detect. Vertical coverage needs the same test: a 90 mm tall field wants 90 mm × 30 px/mm = 2700 pixels, and a 3000-pixel column clears it with 300 pixels to spare. A 5 MP class sensor is about 2600 pixels wide, which covers 2600 px / 30 px/mm ≈ 87 mm — it runs out of field before it runs out of detail.

The requirement is 3600 pixels across. The LS-CMR-0166 reads 4000 × 3000 pixels at 30 fps over USB3.

A rolling shutter suits the still-part case above; moving parts belong to the global-shutter modules from the last section.

What do you verify before you order?

Six checks decide the purchase: the kernel's CONFIG_USB_VIDEO_CLASS line, the protocol the data sheet declares, a runtime build for the board's CPU architecture, the port's power and count, the trigger requirement, and the device-path plan when more than one camera shares the host.

• Kernel line. zgrep USB_VIDEO_CLASS /proc/config.gz answers CONFIG_USB_VIDEO_CLASS=y or =m; both run a UVC camera, an empty answer does not.
• Protocol on the data sheet. USB Video Class means the /dev/video* route; USB3 Vision means the runtime route; a data sheet that names neither is a reject.
• Runtime for the architecture. USB3 Vision runtimes ship per CPU architecture; confirm the build exists for the board's processor before the camera is committed, not after.
• Port power and count. Check the camera's power draw against the port's budget, and count the USB 3.0 ports actually exposed — many boards carry one or two, with the rest on a USB 2.0 bus.
• Trigger. If parts move or a strobe fires, USB camera external trigger support: how to decide tells you what to ask for; expect to land in the USB3 Vision column.
• Device paths. With two or more cameras, /dev/video0 and /dev/video1 swap between boots; Multiple USB cameras on Linux: stop device path conflicts shows how to pin them.

When is the usual answer wrong?

UVC is the wrong column when the part moves: a surface travelling 300 mm/s smears 0.3 mm across a 1 ms exposure. Motion, strobe or trigger requirements push the camera into the USB3 Vision column with its global shutters and hardware trigger lines.

Blur is speed multiplied by exposure: 300 mm/s × 1 ms = 0.3 mm of smear. Holding smear under one pixel at 30 px/mm — 0.033 mm per pixel — needs an exposure of 0.033 mm ÷ 300 mm/s ≈ 0.11 ms, fired from hardware. The video class defines no trigger input, so this requirement settles the argument. UVC camera external trigger on Linux: enable it with V4L2 controls shows what software-side triggering can still do when the part stops for the shot.

A second wrong turn is stacking two UVC cameras on one controller. UVC devices commonly declare more isochronous bandwidth than they stream, so the controller's reservation budget runs out long before the 5 Gbit/s arithmetic says it should. Spread cameras across controllers, or move the machine-vision cameras to USB3 Vision, whose bulk streams do not reserve that way.

A third: if the board must act as a camera for another host — test fixtures do this — the kernel side is the UVC gadget driver, built for the device side of the link rather than the host side. a walk-through of ARM Linux USB gadget MSC and UVC modes shows the configuration.

The decision, case by case:

• Presence, code or orientation check, part at rest: a UVC-compliant camera on the stock image — zero kernel work, first frame in minutes.
• Inspection with strobes, triggers or motion: a USB3 Vision area scan camera or board-level module with the vendor runtime in user space — still no rebuild.
• Several cameras on one board: plan controllers, bandwidth and device paths first; the driver question is the smaller half.
• The board must emulate a camera: that is the gadget driver, a different problem from the one this guide solves.

More Linux-side checks sit on the systems topic page. If you are sizing a camera now, send us the field of view, the feature size and the part speed, and we will return the shortlist with the interface decision already made — or contact us with the numbers.