Claude Wrote a Scanner Driver in a Weekend, and That Reframes Hardware Reverse Engineering

Christian Fredrik Kalager Schaller wanted to scan his late mother’s film negatives. He bought a Plustek OpticFilm 8200i because it was listed as Linux-supported, then found the scanner’s chipset had quietly changed to a Genesys GL128 controller (USB ID 07b3:1825) that no Linux driver handled. Months later, he published a writeup describing how he got a working SANE backend anyway, plus a fixed MIPI camera on his ThinkPad X1 Carbon, by pointing Claude at the problem. The interesting part is not that an AI model wrote C. It is the harness he built around it.

Schaller’s method, now packaged as an open project called hw-harness, is a four-step loop. Run the vendor’s Windows driver inside a KVM virtual machine with the real device passed through. Capture the USB traffic from the Linux host with usbmon, which sits below the passthrough layer so the guest cannot see it. Repeat the same operation with your own driver and capture that too. Then diff the two traces. Both recordings come from the same instrument, so they compare directly, and the differences are a concrete list of driver bugs. For devices with no bus to tap, like an internal MIPI camera, the harness inspects the Windows side instead: INF files, registry data, ACPI tables, device properties.

Why trace diffing is the real unlock

Writing a driver for undocumented hardware has always been a patience problem, not a cleverness problem. You capture bus traffic, stare at hex dumps, form a hypothesis about what a register does, test it, and repeat for weeks. Schaller says as much: “None of it is conceptually hard, but it takes a lot of patience and skills.”

That shape of work suits a model almost perfectly. An agent can read thousands of lines of USB capture, notice a sequence repeating with one byte changing, propose what that byte means, and write the test to confirm it. It does not get bored at hour six. The human still decides what to build and verifies it on real silicon. But the slog collapses.

The critical detail is the reference capture. Schaller notes that for the MIPI camera, having a USB webcam connected so Claude could compare two captures was decisive. A known-good trace against a failing one converts “it doesn’t work” into a ranked list of differences. That is a generalizable pattern, and it is not specific to drivers. Anywhere you have a working system and a broken one, and a way to record both, an agent can do the diffing.

The MIPI camera fixes are the receipts

The ThinkPad work is where the method shows its teeth, because the fixes are specific and checkable. The camera is a Sony IMX471 sensor behind an Intel IPU7. On Linux it produced dark, vignetted images with a yellow-green cast. The kernel-side IMX471 driver had a crop-selection bug that returned an error before storing the crop rectangle, so libcamera assumed the full pixel array. The test-pattern register was declared with the wrong width. The analogue gain cap was too low, costing about 1.8 stops of sensitivity. In libcamera’s software ISP, lens shading correction was missing entirely, leaving corners about 2.7 stops darker, and white-balance statistics were summed at the sensor’s native bit depth against an 8-bit black level, which skewed white balance for any RAW10 or RAW12 sensor.

In a controlled low-light test, frame brightness rose from 31.1 to 90.9. The red/green and blue/green ratios moved from 0.890 and 0.672 to 1.047 and 0.823, close to a USB webcam reference. Blue is still about 17% short in low light, which Schaller attributes to grey-world white balance.

The kernel patches went to Kate Hsuan; the libcamera patches are being reviewed by Wim Taymans for submission upstream. That is a real contribution path, not a demo.

The scanner driver, and the timing joke

The Plustek backend supports color, gray, infrared, and color+infrared modes, resolutions from 300 to 7200 dpi at 8 or 16 bits per channel, dust and scratch removal from the infrared channel, and an exposure multiplier for dense negatives. It ships as a Fedora RPM built on every push. Schaller compared it against upstream SANE’s genesys backend, which gained support for the same scanner in September 2026. Both resolve the same fine detail at 3600 dpi. His is faster at full resolution, 34.6 seconds against 54.4 seconds, and supports infrared dust removal. Upstream offers more resolution steps. He is explicit that these are single-unit, single-frame results and should be treated as one data point, and he expects everyone including himself to use the upstream driver once it reaches parity.

There is a funny coda. After he got his driver working, he discovered someone had already committed support to SANE during the months he had given up. He says it happens sometimes.

The AI is good at the tedium. The human still holds the hardware and decides what to build.

What this means for AI builders

Two things stand out. First, the agent’s value here came from a harness, not from raw model capability. Schaller’s earlier attempts with Claude went nowhere; the breakthrough came when he copied Tom Crider’s (“Glorious Eggroll”) approach of giving the agent full control of a Windows instance to capture reference data. The model did not get smarter between attempts. The scaffolding did. That is a recurring lesson in applied AI work, and it is worth internalizing: the marginal return on better context and better tooling often beats the marginal return on a better model.

Second, this is a quiet argument about where AI agents fit in engineering. The framing that matters is not “AI replaces programmers.” It is “AI absorbs the parts of engineering that are tedious but require attention to detail,” specifically the parts where a human would need to hold a hypothesis across thousands of lines of low-level data. Driver reverse engineering is one instance. There are many others: protocol implementations, format parsers, firmware analysis, fuzzing triage, log forensics.

Schaller is careful about what he is not claiming. He does not claim his scans or his MIPI camera are perfect, only better. He checked every claim on real hardware. He also flags that hw-harness is a generalization of bespoke scripts, so it has not been battle-tested in this exact form.

The honest read is that this is a proof of concept with real artifacts attached. The scanner backend is a proof of concept by his own framing. The camera fixes are narrow, specific to one laptop. But the method generalizes, the harness is public, and the underlying insight, that an AI agent plus a reference capture turns an open-ended debugging problem into a diff, is the kind of thing that quietly changes how a lot of low-level work gets done.

What to watch: whether the SANE project folds his discoveries into the upstream genesys backend, and whether anyone else picks up hw-harness for hardware that has never had a Linux driver at all. The tooling exists now. The question is who points it at the next undocumented chip.