USB camera in lsusb but not detected by the vision SDK on Linux

A USB camera that appears in lsusb but is invisible to your vision SDK is one of the most confusing failure modes on a Linux machine. The bus sees the device, so the cable and connector are basically working, yet the viewer or enumeration tool answers "No device detected". The fault is almost always in software: device node permissions, a driver that never bound, or a kernel module the firmware refused to load because of secure boot. This guide walks the causes in order of likelihood, with the exact command to test each one, so you can fix it in minutes instead of reinstalling the whole stack.

What lsusb does and does not prove

lsusb reads the device descriptors straight from the USB host controller. If your camera is listed there with the right vendor and product ID, three layers already work: power, the physical link, and basic enumeration. That rules out most hardware faults and narrows the problem to the layers above it:

• a kernel driver that did not bind to the device,
• a device node your user cannot open (permissions or udev rules),
• a driver module that the kernel refused to load because it is unsigned and secure boot is on.

The last one is the classic trap. The kernel logs "module verification failed" or "Lockdown ... blocked loading", the device keeps enumerating on the bus, and every SDK built on that module reports no device. If you run several cameras, first rule out the simpler capacity and permission problems covered in multiple USB cameras: diagnose connection limits.

Step 1: Read what the kernel said

Plug the camera in, then read the ring buffer while it is fresh:

1. Unplug the camera.
2. Run sudo dmesg -C to clear the buffer (or note the current time).
3. Plug the camera in and run dmesg | tail -50.

Interpret what you see:

• udev lines naming the camera and a /dev/video* or /dev/bus/usb node mean enumeration is clean; continue to step 2.
• module verification failed: signature and/or required key missing followed by the camera driver's module name means secure boot blocked the driver; go to step 4.
• Nothing at all, or repeated disconnect/reconnect cycles, point to power or cabling; go to step 3.

Also check the negotiated speed with lsusb -t. A depth or multi-sensor camera on a 480 Mbit/s (USB 2) branch will enumerate but cannot stream, and some SDKs then report it as unavailable. That negotiation failure is a different problem, covered in USB camera format negotiation: diagnose rejected modes.

Step 2: Test permissions and udev rules

Vision SDKs install a udev rules file that makes the camera's USB device nodes accessible to non-root users. If it is missing, or was never reloaded, only root can open the camera and the SDK finds nothing.

1. Run your viewer with sudo. If the camera appears, it is a permissions problem, not a driver problem.
2. Check the shipped rules file exists (look in /etc/udev/rules.d/ or wherever the SDK package puts it) and covers your camera's USB vendor and product IDs.
3. Reload and replug:

sudo udevadm control --reload-rules
sudo udevadm trigger

4. Verify the node with ls -l on the device path in dmesg: it should show your user's group and a mode such as 0666.

We cover the video and media node side of this in detail in Linux camera device permissions: video and media node checks. If several depth cameras must come up reliably at boot, see multiple USB depth cameras on Linux: startup troubleshooting for enumeration ordering and power sequencing.

Step 3: Rule out cables, hubs and controller ports

Enumeration succeeding does not mean the link is stable. Long passive cables, unpowered hubs and front-panel ports cause cameras that appear, then vanish under load. When a USB camera must sit far from the machine, use a shielded cable rated for drag-chain duty rather than extending an office-grade one.

A high-flex USB3 camera cable holds the link in moving installations. If dmesg shows resets, swap the cable, plug the camera directly into a rear controller port, and try a different USB controller if the machine has more than one. For cameras carried on a robot arm, the routing and fatigue checks in robot camera cable failures: routing and fatigue checks prevent this whole class of intermittent faults.

Step 4: Check whether secure boot is blocking the driver

This is the cause most engineers reach last, and on small industrial PCs it is very common. Secure boot verifies that every kernel module is signed by a trusted key. Vision SDKs that ship an out-of-tree kernel module for their cameras often install it unsigned, or signed with a key the firmware does not trust. The kernel refuses to load the module, the driver never binds, and the SDK reports no device while lsusb happily lists the camera.

Confirm it:

1. Run mokutil --sb-state. If it reports SecureBoot enabled, the suspect is live.
2. Re-run the step 1 dmesg check and look for the signature or lockdown message naming your camera driver's module.
3. Try loading the module by hand with sudo modprobe <module>; the same error appears inline.

Two legitimate fixes exist, and both are the vendor-supported path:

• Disable secure boot. Enter firmware setup during boot, clear or disable the secure boot policy, reboot, and reload the module. This is the standard fix on a lab or bench machine.
• Enroll the module's key. Sign the module with your own key and enroll that key in the machine owner key (MOK) list with mokutil. Secure boot stays on and the module loads. Prefer this on production machines, where the boot integrity policy matters.

For a related angle on firmware security and boot chains on embedded industrial machines, the knowledgebase article on the secure boot chain in embedded Linux goes deeper into what secure boot actually verifies.

Step 5: Fix the software stack once the driver loads

After the module loads and the device node appears, the SDK should enumerate the camera. If enumeration now works but streaming misbehaves, the remaining suspects are software version mismatches between the SDK, the driver module and the camera firmware. The diagnostic path for those is in camera SDK build mismatch: diagnose frame timeouts, and for linker or loader errors when you build against the SDK yourself, see GenTL camera open failure after successful discovery.

If you patched or replaced a stock kernel driver while chasing this and the system became less stable, the rollback procedure in Linux uvcvideo driver rollback after patch failures gets you back to a known-good module.

Choosing hardware that avoids the problem

USB cameras that run on a standard UVC class driver need no out-of-tree module at all, so secure boot never enters the picture. Depth and ToF cameras more often need a vendor module, so plan the signing step into your deployment. For depth sensing without a vendor kernel module, a ToF camera that presents standard device classes is the low-friction choice.

Browse the 3D sensors category for laser profilers, stereo and ToF options, or the area scan cameras finder for USB3 industrial cameras. Cables and connectors for fixed installations are in camera cables, and the system configurator walks camera, cable and host choices in one pass.

Prevention checklist

• Enable the vendor's udev rules at image build time, not after the first failure.
• Decide the secure boot policy before deployment: disable it on benches, sign and enroll module keys on production machines.
• Record mokutil --sb-state and lsusb -t output in your machine's commissioning log so later faults compare against a known-good state.
• Keep the SDK, driver module and camera firmware on versions the vendor documents as tested together.
• Use rated, shielded cables and direct controller ports for multi-sensor cameras; reserve hubs for keyboards.

Work through the steps in this order (kernel log, permissions, cabling, secure boot) and you isolate the layer at fault in a single reboot. If the camera still refuses to enumerate after the driver loads and permissions test clean, contact us with the dmesg output and we will help you read it.