Depth camera firmware mismatch after a shared camera swap

A USB depth camera is often a shared asset: one engineer borrows it for a Windows demo, another plugs it into a test bench, and a month later the camera that streamed perfectly on your Linux box refuses every application with UVCIOC_CTRL_QUERY:UVC_GET_CUR error 56, Invalid request code. The error looks like a driver or kernel problem, and you can waste a day re-appatching uvcvideo before finding that the camera itself changed while it was away. This guide gives an isolation sequence — budget about 30 minutes for the first five checks — that separates hardware, kernel-patch and firmware causes, shows how to read the camera's reported firmware version, and lays out the vendor-supported recovery path.

What error 56 tells you, and what it does not

The UVC control query UVC_GET_CUR asks a camera for the current value of a control. Error 56 means the device answered that the request code itself is invalid: the driver asked for a control the camera's firmware does not expose, or exposed under a different request. It is a protocol-level disagreement between your kernel driver and the firmware inside the camera, not a data error.

That gives you a first split:

• Same error from every sample, including enumeration-only tools, on the same PC, kernel and cable that worked before: the driver-to-firmware contract is broken. Suspect a firmware version change.
• Error appears in one tool but not another: version or build mismatch in the SDK; see camera SDK build mismatch: diagnose frame timeouts.
• Error appears only after running for a while, or with corrupted images: look at bandwidth and power instead — depth camera black image: fix USB bandwidth and power issues.

Isolate in order of probability

Work through these checks before touching firmware. Each takes under 5 minutes and eliminates a whole class of causes.

1. Confirm the kernel. Run uname -r and verify it is the kernel you patched. A distribution update can boot a newer kernel with a stock uvcvideo module while your patched module sits unused. If you re-patched and the log still shows unresolved pixel formats, the patch did not apply to the running kernel.
2. Check permissions. A permissions failure also blocks every sample. Verify the /dev/video* and media device nodes are accessible to your user as covered in Linux camera device permissions: video and media node checks.
3. Try every port and a powered hub. Three ports failing identically is strong evidence the physical layer is fine. Note it and move on; do not spend an hour swapping cables.
4. Test the camera on a second machine. If it also fails on a clean host with a matching SDK and driver, the camera — not your kernel — is the problem. If it works there, compare driver and SDK versions between the two hosts.
5. Run the enumeration sample. Enumeration prints device identity and firmware strings without configuring streams. If it fails too, the mismatch is at the control level, which is exactly where a firmware change bites.
6. Read the kernel log during the failure. About 50 lines captured while the error occurs tell you whether uvcvideo rejects the pixel format (patch problem) or the device rejects the control query (firmware problem). If re-applying the patch does not change the log, stop re-patching and look at the camera.

Check the reported firmware version

The definitive test is the version string the camera itself reports:

1. Connect the camera directly to a known-good USB port.
2. Run the SDK's enumeration tool (often named like enumerate-devices or cpp-enumerate).
3. Read the Firmware version: line it prints.
4. Compare it against the firmware version your SDK and driver patch were validated with, in the release notes.

A version that does not match your SDK's supported range is your answer. Write down the exact string — you will need it when you restore the camera and when you verify the fix afterwards.

If enumeration cannot even open the device, the camera may be rejecting the control queries too. Permissions and cable checks come first; once enumeration opens the device, the version line is trustworthy.

Restore the camera with vendor tools

Recovery means bringing the camera back to a firmware version your host's SDK supports, using only the manufacturer's own firmware or device-manager tooling. Plan 15–30 minutes end to end:

1. Find the matching tool version. Download the SDK or device manager release whose release notes name the firmware version you want, from the manufacturer or its distributors only.
2. Install it on a host the tool supports. Firmware tools are commonly Windows-only; that is fine, the camera does not care which OS wrote its firmware.
3. Select update (or reinstall) firmware. Choose the version your Linux SDK expects. Reinstalling the same version is also legitimate when the string is unknown.
4. Let it finish, however long step one takes. Some writers sit on the first step for ten minutes or more. Never unplug mid-write.
5. If the tool errors out, leave the camera connected, record the step number and message, and follow the manufacturer's documented recovery or support procedure. Do not power-cycle and retry blindly.
6. Verify on the original host. Reconnect to your Linux machine, rerun enumeration, and then run a streaming sample for at least 5 minutes without a single control error. The firmware string should now match.

If the camera had also picked up a write-protected or locked control state while away, reconnection can surface that separately — camera feature write-protect errors after reconnection covers it.

The kernel patch question

A patched uvcvideo driver exposes depth formats the stock driver does not, and an incompletely applied patch produces errors that look similar. The reliable sequence:

1. Note the running kernel with uname -r.
2. Remove any previously generated build folder in the SDK source tree so stale artifacts cannot be reused.
3. Rerun the vendor's patch script for that exact kernel.
4. Unload and reload the module (rmmod uvcvideo, then insmod the freshly built module).
5. Capture the kernel log and confirm the depth formats now resolve.

If the log is clean but the camera still rejects control queries, the patch is fine and the firmware is the remaining suspect. Rolling the driver back and forth will not change a firmware version mismatch; that is covered from the driver side in Linux uvcvideo driver rollback after patch failures.

Hardware that makes the whole class of problem smaller

Not every depth camera shares a USB port with borrow risk. Fixed installations with a dedicated interface card and locked-down hosts stop the camera wandering between machines and SDK versions.

For hosts that stay put, a multi-port USB3 adapter keeps the camera on one machine and one SDK:

Browse depth and ToF cameras for sensors intended for fixed installations, or frame grabbers when you want the acquisition hardware inside the workstation rather than dangling on a cable. If you are rebuilding the whole acquisition chain, the system configurator walks camera, lens, light and interface choices in order.

Checklist before you call it fixed

• Enumeration prints the expected firmware version string.
• A streaming sample runs without any UVC control errors for at least 5 minutes.
• uname -r still shows the kernel you patched, after a reboot.
• The camera is labelled with its validated firmware version and designated host.
• Everyone who borrows the camera knows not to accept firmware updates offered by other software.

For multi-camera benches, also re-check enumeration after a cold boot — multiple USB depth cameras on Linux: startup troubleshooting covers the node-ordering problems that appear once the firmware question is settled.