Depth camera UVC SET_CUR control failed: USB3 and vendor units

You plug in a depth camera, the kernel enumerates it without complaint, three UVC video nodes appear — and then every capture tool comes back empty while dmesg floods with "Failed to query (SET_CUR) UVC control" lines ending in -32. Two problems hide behind that one symptom: a generic UVC stack writing vendor-defined controls the camera refuses, and a link that never reached the SuperSpeed the device's own descriptor demands. Below you decode the -32 line, read the descriptor that rules out USB 2.0 ports, work the link-speed arithmetic for a real three-stream camera, and follow a fix order that ends with the camera streaming through its vendor library.

The signature: it enumerates as three UVC nodes and streams nothing

The camera passes every plug-in check. lsusb lists it with its product string, the kernel binds each UVC function in turn — a combined left-right stream, a depth stream and a color stream, each as its own video node — and even registers the button input devices the camera exports.

Then the capture stack configures the streams, and the kernel log fills with repeats of one line:

uvcvideo: Failed to query (SET_CUR) UVC control 1 on unit 7: -32 (exp. 2).

The timestamps give away the rhythm: 10378.408970, 10378.459518, 10378.509925 — each line lands about 50 ms after the last, one stalled control write per attempt, as the stack retries its way through stream configuration. Nothing you open gets a single frame: webcam capture tools, the raw V4L2 API, a launch file in your robotics stack.

There is a second clue at plug-in time, easy to miss:

uvcvideo 2-3:1.0: Entity type for entity Extension 2 was not initialized!

The driver met an entity in the camera's descriptors that it has no mapping for. That entity is the vendor extension unit, and it sits at the heart of the problem. If no video nodes appear at all, you have a different failure — start from a known state instead: clear leftover settings and re-plug on a known-good port, as in the flaky camera test from leftover settings.

What -32 means: the camera stalled the control request

-32 is the kernel's errno 32, EPIPE. On a USB control transfer, EPIPE is how the host reports that the device answered STALL: the request reached the camera, and the camera refused it. This is not a timeout, not a disconnection and not a permissions problem — the camera is answering, and the answer is "not that way".

SET_CUR is the USB Video Class "set current value" request. In the log line, "control 1" is the control selector the driver tried to write, "unit 7" identifies the entity inside the camera, and "(exp. 2)" is the 2-byte data stage the driver expected. In this camera's descriptor, unit 7 is the processing unit behind the color stream; the same descriptor carries an extension unit exposing 21 vendor controls, which the driver logged as uninitialized at plug-in. Controls behind entities like these follow the camera maker's own protocol, not the class defaults, so each generic write stalls and the loop marches on 50 ms at a time.

The decision rule is simple: a stream start that floods SET_CUR -32 means the stack is speaking a protocol the camera does not implement. Stop treating the camera as a webcam. The USB Video Class specification lets a camera expose vendor-specific controls through extension units, and driving those controls needs userspace support that knows them — that support is the vendor's library, not the class driver.

Likely causes, in order of probability

1. The generic UVC stack is driving vendor controls. The signature matches exactly: an uninitialized Extension entity at plug-in, then the SET_CUR flood the moment streams are configured. Test: start the vendor library and watch whether the flood stops. Fix: the steps in the next two sections.
2. The link is running at 480 Mbit/s, not 5 Gbit/s. A USB 2.0 port, a non-SuperSpeed hub, or a worn cable drops the camera to high-speed. Test: read the plug-in line in dmesg — "new high-speed USB device" instead of "new SuperSpeed USB device" indicts the link, not the software. Fix: a native USB 3 port, no hub, a USB 3-rated cable.
3. Firmware and library do not line up. Firmware older than the library release expects can reject controls and stream formats the new stack assumes. Test: read bcdDevice from the lsusb -D output and match it against the release notes of the library version you installed. Fix: run the vendor's documented firmware update once, then reinstall the matching library; the same skew pattern is covered in the firmware and SDK alignment failure.
4. A marginal cable fails control writes intermittently. Enumeration survives; the first control burst does not. Test: swap in a known-good short cable from the camera data cables range — if the flood vanishes, chase the link, not the library.

Causes 1 and 2 usually travel together: the vendor library refuses to start on a 480 Mbit/s link too, so fix the link first no matter which library you run.

Worked example: the link floor of a three-stream depth camera

The inputs, and where each comes from:

• From the camera descriptor, read with lsusb -D /dev/bus/usb/...: bcdUSB 3.00; a SuperSpeed USB Device Capability block printing wSpeedsSupported 0x0008 and bFunctionalitySupport 3; three bulk IN streaming endpoints, each printed as wMaxPacketSize 0x0400 1x 1024 bytes.
• From the plug-in log: usb 2-3: new SuperSpeed USB device number 8 using xhci_hcd.
• USB limits: a Hi-Speed link runs at 480 Mbit/s and allows bulk endpoints of at most 512 bytes; SuperSpeed allows 1024-byte bulk packets at 5 Gbit/s.

The rule in words: a bulk endpoint negotiates only at link speeds where its max packet size is legal, and the capability descriptor names the slowest speed at which the device stays fully functional.

The arithmetic:

• wMaxPacketSize 0x0400 = 4 × 256 = 1024 bytes. Hi-Speed caps bulk packets at 512 bytes, so 1024 > 512 makes these endpoints illegal at 480 Mbit/s and legal only at SuperSpeed.
• wSpeedsSupported 0x0008: 8 = 2³, so only bit 3 is set and bits 0–2 (low, full, high speed) are clear. The camera advertises exactly one operating speed, and bFunctionalitySupport 3 agrees: its lowest fully-functional speed is SuperSpeed, which lsusb prints as "Lowest fully-functional device speed is SuperSpeed (5Gbps)".
• Even if a slower mode existed, the bandwidth would not carry three streams: 480 Mbit/s ÷ 8 = 60 MB/s raw, and real Hi-Speed bulk traffic typically lands near 40 MB/s — about two-thirds of raw — once transaction overhead and bit stuffing are paid. The camera's three bulk pipes, one per stream, all share that.

The result: this camera has no operating mode below 5 Gbit/s. Enumeration at 480 Mbit/s is not a degraded stream — it is no stream. The controller name in the working plug-in line, xhci_hcd, also confirms the device landed on the host's USB 3 host controller rather than a companion port.

The decision: make that plug-in line the gate. "new SuperSpeed USB device" counts as a working link; anything slower means the port, cable or hub chain gets fixed before any software is touched.

The fix in order: link, firmware, vendor library

1. Prove the link speed. Unplug, replug, read dmesg. Require the "new SuperSpeed USB device" line before anything else; if it says high-speed, move the camera to a native USB 3 port on the host and take any hub out of the chain.
2. Read the descriptors. Run lsusb -D on the device node and confirm the SuperSpeed Device Capability block and the 1024-byte bulk endpoints from the worked example. Note bcdDevice while you are there: it is the firmware release number for step 3.
3. Align firmware and library. Check the vendor's release notes for the library version you installed and the minimum firmware it documents; where they disagree, run the vendor's documented firmware update once and reinstall the matching library. Where firmware is the only mismatch, that update plus the matching library is the whole fix.
4. Install the vendor library and make it the only access path. Its userspace component knows the extension unit controls the class driver logged as uninitialized. Apply the vendor's Linux installation notes exactly, including any driver-stack change they request; if that touches kernel sources, match versions precisely as in the UVC patch kernel mismatch fix.
5. Verify with the vendor's capture example first. Streams arriving with no SET_CUR lines in dmesg means the camera is being driven correctly. Only then start your robotics stack or your own code on top.
6. Re-run the sequence after any hardware change. A new cable, dock or host moves the link speed first; step 1 catches it in seconds.

Checks that prevent the next failure

• Port: native root-hub USB 3 port. A hub that is not SuperSpeed on its upstream side is the most common way a 5 Gbit/s camera lands at 480 Mbit/s.
• Cable: USB 3-rated and as short as the run allows. Long passive copper runs invite speed fallbacks and control-transfer time-outs — see the USB cable length limits for 3D cameras and the USB-C cable timeout guide.
• Motion axes: treat cabling as a wear part. The LS-CBL-0219 is a 3 m USB3.0 camera cable with high-flex, drag-chain-rated construction.

• One stack: the vendor library owns the camera. Webcam tools and the SDK fight over the same video nodes.
• No VMs: a virtual machine's USB pass-through adds control-transfer time-outs of its own; the depth camera stream time-out in a VM shows the pattern.
• Record bcdDevice and the library version at commissioning. When either changes, re-check the vendor matrix before the next shift.

When to replace the camera instead

If the vendor has stopped maintaining the library — it will not build on current kernels, or no firmware release covers your host's driver stack — the rescue can cost more than a replacement. The 3D sensors range covers the main depth-camera types: the MV-DT01WMU is a ToF sensing camera and the MV-DPS200P-02 is a projected structured-light 3D camera. Pick by the geometry you need — volume, pose or profiles — and let the camera finder narrow the field.

Whichever way you go, run the firmware-and-library alignment check from the fix section on day one, and let the configurator walk the platform and interface choices:

Other depth-camera failure patterns sit on the 3D camera topic page. If the fix order above does not clear your signature, send the lsusb -D output and the dmesg lines through the contact page — the descriptor and the plug-in line usually name the remaining culprit between them.