Depth camera kernel patch failure: fix or avoid it

You checkout the exact kernel tag the vendor names, run the patch script, and one hunk still fails: Hunk #1 FAILED at 153, with rejects saved to a .rej file. The camera will not stream until the patched driver is built, so the failure blocks everything downstream. This article explains why the mismatch happens, how to read the patch output, and how to choose between fixing the patch, installing a DKMS package, or switching to a user-space backend that needs no patching at all. If your symptom is a dark or black image rather than a failed build, see the guide on a depth camera black image caused by USB bandwidth and power.

First, read what patch actually told you

The patch output is diagnostic, not noise. Each line tells you how well the patch matched your kernel source:

• patching file ... with no comment: the hunk applied cleanly.
• Hunk #1 succeeded at 208 (offset 5 lines): the code had moved, but patch found it. This is harmless.
• succeeded ... with fuzz 2: patch matched while ignoring two lines of context. Usually harmless, occasionally a sign the code has drifted.
• Hunk #1 FAILED ... saving rejects to file ....rej: the context lines no longer exist in that order. That file was not modified.

A hunk is a block of changes plus a few unchanged context lines around it. Patch searches for those context lines near the line number given in the hunk header. If a kernel update restructured the driver, added a function, or reordered includes, the context no longer matches and the hunk fails. Offsets and fuzz are warnings; failures are hard stops.

Find the real cause: version mismatch

Ask three questions, in this order:

1. Does the patch match this kernel line? A patch series built for the 4.15 long-term-support line will usually fail against 5.x or 6.x sources, because the UVC driver in drivers/media/usb/uvc/ is actively developed. Check the vendor's supported kernel list for the exact SDK version you downloaded.
2. Did you check out the exact tag? If the instructions name a specific Ubuntu tag, git describe --tags in the kernel source folder should print it. A near-miss tag one point release away can carry just enough change to break a hunk header.
3. Is the SDK and patch set current? Older SDK versions carry older patches. Updating the SDK often fixes the failure with no other work, and updating the camera firmware alongside it resolves a second tier of control and enumeration warnings.

Fixing a single failed hunk by hand

When only one small hunk fails and you must stay on the patched-driver path, manual application is reasonable:

1. Open the .rej file. It repeats the hunk header and the intended change.
2. Open the target file and search for the nearest surviving context line from the hunk.
3. Apply the same edit at the new location, keeping the intent, not the literal line numbers.
4. Re-run the patch script with --dry-run until it reports no failures, then build.

This works because the change itself is usually a few lines, such as a new control ID in a header. It stops working the moment you update the kernel: your edit is gone, and the next patch run fails again.

Prefer DKMS: the vendor-maintained route

Most camera vendors that once required kernel patches now ship their driver as a DKMS package. DKMS registers the driver source with your package manager and rebuilds the module automatically every time a kernel update installs. You trade one manual step for an unattended one:

1. Install the vendor's DKMS package from its own repository.
2. Reboot into the new kernel and confirm the module loaded.
3. Check dmesg for the driver's probe messages rather than assuming.

The advantage is structural: the vendor updates the patches when kernels change, so the hunk-matching problem becomes their maintenance task, not yours. If a DKMS build does fail after a distribution update, it fails loudly with a build log, which is far easier to report and fix than a silently reverted manual patch.

The user-space backend: no patching at all

Many depth camera SDKs offer an install mode that skips the kernel entirely. The SDK talks to the camera over generic USB libraries from user space, so it depends on no kernel version and no UVC patch. For one camera on a desktop-class host this is often the fastest way to a working stream, and it sidesteps the entire patch-versus-kernel problem described here.

The trade-offs are real:

• Bandwidth and multi-camera set-ups may behave differently, because the generic path negotiates transfers differently from the in-kernel driver. If you run several cameras on one host, read the notes on multiple USB depth cameras on a single Linux machine before committing.
• Some controls may be unavailable or behave differently, since you lose the in-kernel media controller integration.
• Frame drop counts should be measured, not assumed. Stream for 10 minutes at full resolution and compare drop statistics between backends; a healthy set-up holds zero dropped frames.

A reasonable rule: use the user-space backend for development, evaluation and single-camera cells; use DKMS for production machines where you want the vendor's maintained kernel path.

When the patch war is a signal to change hardware

If your reason for patching is a discontinued or consumer-grade depth camera, the maintenance cost never goes away. Every distribution upgrade re-runs the fight. Industrial depth cameras designed for long-term deployment ship with drivers maintained for current kernels, so the patch step disappears from your install procedure.

For profile-based inspection, a laser profile sensor such as the MIS-DP3850-01P takes the same approach of vendor-maintained drivers:

For projected structured-light capture on a stationary part, a camera such as the MV-DPS200P-02 covers the same class of work with an SDK maintained against current kernels:

Browse the full range in the 3D sensors category, or use the camera finder to filter by interface and depth technology. If you build the camera into your own machine rather than buying an integrated sensor, board-level cameras are the lighter alternative, and the guide on board-level camera selection for embedded vision machines covers that decision.

Checks before your next install

Run through this list on any machine where a patched driver previously failed:

• uname -r matches a kernel the SDK version explicitly supports.
• The kernel source folder is at the tag the vendor names (git describe --tags).
• The SDK and patch set are the current release, and the camera firmware is current.
• A DKMS package exists for this SDK; if yes, you do not need manual patching at all.
• After install, dmesg shows the driver probing the camera, and a 5-minute stream reports zero dropped frames.
• You have recorded the kernel version and SDK version together, so the next failure can be reproduced and reported.

For set-ups where format negotiation or exposure controls misbehave after a driver change, the troubleshooting guide on USB camera format negotiation helps separate driver issues from camera-mode issues.

Short checklist

• Hunk failure means context drift, not a broken tool: match the kernel tag first.
• Offsets and fuzz are fine; .rej files are the real signal.
• Manual .rej fixes are a one-kernel stopgap.
• DKMS moves patch maintenance to the vendor.
• User-space backends remove kernel dependence; measure drop counts.
• Recurring patch pain on one camera model is an argument for a production-grade depth camera with maintained drivers.

If a build or enumeration problem persists after all of this, the closest related guide is the uvcvideo driver rollback walkthrough, which handles the recovery side after a driver change goes wrong. And if you would rather specify hardware that does not need kernel patching at all, tell us the part geometry and cycle time through the contact page and we will suggest a set-up; free expert support comes with every order.

One further reference worth reading if your host is an industrial IoT box rather than a PC: the guide to fixing a UVC camera that is not recognized on a Linux CIP kernel covers kernel-configuration causes that sit upstream of any patch. For the capture side of a multi-camera host, see multiple camera modules on one host: shared bus limits.