Uvcvideo module not loaded: check for a built-in driver

A camera can have working Linux video-driver support even when an SDK reports that uvcvideo is not loaded. The driver may be compiled into the running kernel rather than installed as a loadable module. A check of the loaded-module list cannot distinguish that arrangement from missing support.

For an integration or maintenance engineer, the useful question is whether the required capture interfaces work. Follow the checks below to separate kernel configuration, device permissions, format support and SDK initialization before changing a working kernel.

Separate module presence from driver availability

Linux can compile UVC camera support into the kernel or provide it as a loadable module. Both arrangements can expose video capture through V4L2. Neither guarantees that every camera function required by an SDK is available.

The configuration symbol to inspect is CONFIG_USB_VIDEO_CLASS. Its value describes how the kernel was built, not whether a particular camera has successfully started streaming.

A module-presence check becomes suspect when built-in support is confirmed and direct capture works. Until then, treat the message as a starting point rather than a diagnosis.

For broader failures after USB enumeration, use USB camera detection checks for Linux SDKs. Those checks address discovery problems beyond the built-in-driver case.

Verify the configuration of the running kernel

Start by recording the kernel release and checking the loaded-module list:

uname -r
lsmod | grep '^uvcvideo[[:space:]]'

No matching line means uvcvideo is absent from that list. It does not prove the driver is unavailable.

If the running kernel exposes its configuration, inspect it directly:

zgrep -E '^(CONFIG_USB_VIDEO_CLASS=|# CONFIG_USB_VIDEO_CLASS is not set)' /proc/config.gz

If that file is unavailable, a distribution may provide a release-specific configuration:

grep -E '^(CONFIG_USB_VIDEO_CLASS=|# CONFIG_USB_VIDEO_CLASS is not set)' "/boot/config-$(uname -r)"

Interpret the result as follows:

• CONFIG_USB_VIDEO_CLASS=y: UVC support is built in. An empty lsmod result is expected for this driver.
• CONFIG_USB_VIDEO_CLASS=m: support requires a matching loadable module. Check installation and loading through the supported operating-system procedure.
• # CONFIG_USB_VIDEO_CLASS is not set: this configuration does not include the UVC driver.
• No readable configuration or no matching line: the evidence is incomplete. Obtain the configuration associated with the running kernel from the platform's supported source.

A configuration file left over from another build is not reliable evidence. Match the booted image, its release and its supplied build configuration.

The installed built-in-module inventory can provide corroborating evidence:

grep -E '(^|/)uvcvideo\.ko' "/lib/modules/$(uname -r)/modules.builtin"

A missing inventory file is not proof of missing support, particularly on custom embedded installations. Likewise, a matching entry describes the installed inventory; verify that it belongs to the image actually booted.

If build trees and installed kernel files disagree, resolve that first. The kernel source-tree matching guide explains why release labels alone are insufficient when preparing a rebuild.

Check driver binding and application access

Next, establish whether the camera reaches the video subsystem. Connect it using the intended port and cable, then inspect USB enumeration and recent kernel messages:

lsusb
journalctl -k -b --no-pager
v4l2-ctl --list-devices

Kernel-log access may require an authorized administrative account. If journalctl is unavailable, use the operating system's supported kernel-log facility. Look for camera registration, disconnects, transfer errors and failed interface initialization.

A camera may expose several video nodes, including separate image streams or metadata interfaces. Select the node associated with the intended image stream; /dev/video0 is only the example used below.

Check the application's access using the same account and execution environment that runs the SDK:

id
ls -l /dev/video0
v4l2-ctl --device=/dev/video0 --all

Successful access from an administrative shell does not establish access from a service or container. Check group membership, device permissions and any configured device-access restrictions. After changing group membership, start a new login session or restart the affected service as appropriate.

Do not replace a permissions diagnosis with unrestricted device permissions. Use the platform's documented group or device-rule configuration. The Linux video and media node permissions guide covers that branch in more detail.

If the node cannot be opened, fix that failure before investigating an SDK's module check. If opening succeeds but the SDK still fails discovery, continue with isolating camera SDK access errors.

Enumerate the capture formats the SDK needs

Driver availability and format compatibility are separate questions. A camera can register successfully while its required depth, infrared or image format remains unavailable through the selected backend.

Enumerate the capture modes on the correct node:

v4l2-ctl --device=/dev/video0 --list-formats-ext

Compare the returned pixel formats, dimensions and frame intervals with the SDK's documented requirements. Repeat the check for each image stream the application needs. A working color stream does not establish that a separate depth stream is supported.

For an SDK that uses V4L2 capture, format enumeration is stronger evidence than the loaded-module list. At the API level, applications commonly inspect formats through VIDIOC_ENUM_FMT, then inspect supported sizes and frame intervals where available.

However, enumeration alone does not prove that streaming will succeed. Nor does it establish support for device-specific controls, metadata, calibration access or synchronization.

If the required format is missing, follow Linux kernel support checks for rejected depth-camera formats. That is a different fault from a false module-presence failure. Changing an SDK's startup check cannot add an absent kernel format.

Prove streaming with a controlled test

Close other viewers and applications using the selected capture node. First test a mode actually returned by enumeration, rather than requesting an arbitrary resolution or frame rate.

For example, only if enumeration offers YUYV at the settings below, configure and test it with:

v4l2-ctl --device=/dev/video0 \
  --set-fmt-video=width=640,height=480,pixelformat=YUYV \
  --set-parm=30

v4l2-ctl --device=/dev/video0 --get-fmt-video --get-parm

timeout 10s v4l2-ctl --device=/dev/video0 \
  --stream-mmap --stream-count=60 --stream-to=/dev/null

Read back the accepted settings. Drivers may adjust a request, and some devices do not expose frame-rate control through the same mechanism. Use the mode and control method the driver actually supports.

The timeout prevents this diagnostic from waiting indefinitely. A timeout, incomplete frame count or transfer error means capture has not been demonstrated successfully. Record the tool output and kernel messages rather than treating any activity as a pass.

Put numbers around the result

At an accepted rate of 30 frames per second, collecting 60 frames requires approximately 2 seconds of frame acquisition. Initialization and scheduling add time, so this is not an exact wall-clock acceptance limit.

For uncompressed YUYV, the nominal packed image payload uses 2 bytes per pixel. The example payload calculation is:

This estimate excludes protocol overhead, metadata, padding and additional streams. It is not the bandwidth requirement for an entire multi-stream camera.

Discarding frames into /dev/null tests capture without saving image files. Follow it with image inspection in a supported viewer: completed buffers alone do not prove meaningful image content or valid depth values.

Finally, repeat a comparable stream test through the SDK under the same account. Record the accepted modes and active streams so that the comparison remains useful.

Choose the fix from the evidence

Use the narrowest supported correction that explains the observations.

When evidence points to an SDK assumption, prefer a supported update that explicitly accommodates the installed kernel configuration. Obtain software and release documentation from the manufacturer or its authorized distribution channel.

Do not delete an initialization check merely because its message appears inaccurate. Establish what the check protects, and use a documented correction or a maintainer-supported change. A successful low-level stream does not prove every SDK prerequisite.

When comparing SDK releases, preserve the known configuration and change one component at a time. The camera firmware and SDK alignment guide helps distinguish a startup-check problem from a genuine version mismatch.

Rebuild only when the supported stack requires it

Changing UVC support from built-in to modular can satisfy software that insists on finding a loaded module. That does not establish a general technical requirement for UVC capture.

A rebuild is justified when the documented platform configuration requires modular support, a necessary capability is absent, or the supported integration explicitly depends on module replacement. It is not the first response to an empty lsmod result.

Before rebuilding, preserve the working boot image, configuration and matching modules. Prepare the platform's documented recovery method and verify that it is available locally. Perform the change during an approved maintenance window, then repeat device discovery, permissions, format enumeration and streaming tests.

Do not substitute an unrelated kernel build or copy a module from another release. If a previous supported image worked, the driver rollback guide provides a separate recovery path without assuming a rebuild is necessary.

Check compatibility before ordering or handing over

An interface label is not a Linux driver-class guarantee. USB3 describes an interface, while UVC describes a device class. A camera sold with USB3 connectivity may require a different acquisition backend.

For replacement hardware, begin with area scan cameras for image acquisition or 3D sensors when the application needs depth. Use the camera finder to narrow the hardware, then confirm operating-system, architecture and SDK support separately.

The LS-CMR-0166 is listed as a USB3 area scan camera. Its interface listing alone does not establish UVC compatibility.

The MV-DT01WMU is listed as a ToF sensing camera. The catalog context does not establish its Linux backend or kernel requirements.

Before accepting a fix or selecting a replacement, collect this evidence:

• Running kernel: release, configuration source and UVC build setting, so the deployment can be reproduced.
• Application environment: account, service or container details, so access checks apply to the real application.
• Capture interfaces: node-to-stream mapping, so metadata and image nodes are not confused.
• Required modes: enumerated and accepted formats, dimensions and frame rates, so compatibility is explicit.
• Streaming result: frame count, errors and representative image checks, so a startup message is not mistaken for successful acquisition.
• Supported software combination: SDK, operating system and firmware requirements, confirmed through official documentation.

Use the camera configurator to organize a replacement system, or send this evidence through application support before committing to a kernel change.