In the past, Linux developers have struggled to build drivers for undocumented hardware. Now, with Claude’s help, the problem has become much more tractable.

Christian F.K. Schaller, long-time Linux kernel developer and Red Hat‘s director of software engineering, wanted to digitize some old family photographs. Simple enough, so he bought a negative photo scanner, a Plustek OpticFilm 8200i, only to find that the new model no longer supported Linux. What’s a Linux developer to do? Well, reverse-engineer the Windows driver, since Plustek wasn’t helping, of course! However, that’s a slow, tedious problem to do by hand, so Schaller decided to sic Claude Code on the driver problem instead. It worked, in a word, great.

This wasn’t a push-button Windows-to-Linux driver converter. Nor was Schaller decompiling Microsoft-platform drivers and translating their code. Instead, he uses the vendor’s working Windows driver as a reference, captures what it does, and has the AI turn those observations into Linux code.

The result was hw-harness, an open-source project that provides “Tooling for working out how a piece of hardware behaves so that you can write a Linux driver for it.” The toolkit also comes with Windows VM controls, device-transfer utilities, and inspection tools. For hardware without an accessible USB connection, such as an internal MIPI camera, it collects information including driver INF files, registry data, ACPI tables, and device properties. It deliberately avoids examining the vendor’s .sys executable code. While still quite new, it works well.

This wasn’t his first effort. He’d tried earlier with Claude to write a Scanner Access Now Easy (SANE) scanner backend, but he stalled out. Then, months later, Schaller saw Tom Crider, AKA GloriousEggroll, describe how he used AI tooling on a Windows instance to fix a Linux mouse driver.

Then, inspired by Crider’s work, he used Claude Code to automate the old way of building Linux drivers from Windows drivers. Previously, developers installed the driver on Windows, captured the traffic while performing a specific action, and worked out what the messages meant. It was slow, painful work.

Back in 2004, and until recently, developers used USB Snoopy and SnoopyPro to record USB requests and responses. Then programmers used Perl and shell scripts to filter the output into something understandable.

The process, both then and now, looks like this. It starts by passing the physical device through to a Windows virtual machine (VM) running under Linux’s built-in hypervisor, KVM. The manufacturer’s driver operates the device, while Linux’s usbmon captures its USB traffic from the host, outside the VM. The developer then runs the equivalent operation using the Linux implementation and records that traffic with the same tool. Comparing the captures exposes behavioral differences to investigate.

AI makes this much easier. As Schaller said, “It can read thousands of lines of USB capture, notice that a sequence repeats with one byte changing, and propose what that byte means. It can write the test to confirm it, and it doesn’t get bored.” In short, “I think the combination of having the ability to run scans under Windows and capture the USB data while doing so worked wonders.”

The results? Within hours, he reported, he had a recognizable scan under Linux. Several days later, he had what he described as a “near-perfect driver,” including infrared scanning support. Today, his backend supports color, grayscale, and infrared scanning, along with infrared-based dust and scratch removal.

Still, as Schaller commented, “A driver alone isn’t much use if scanning negatives is still painful, so I built Negative Vibes. It’s a GNOME app, written in Rust, for scanning color and black-and-white negatives and slides on any film-capable SANE scanner.”

This isn’t a one-off effort. Schaller next applied his approach to the camera in his Lenovo ThinkPad X1 Carbon Gen 14 Aura Edition, which uses a Sony IMX471 sensor behind Intel’s IPU7. A Linux driver already existed, but frankly it didn’t work that well.

Under Linux, the camera produced dark images, pronounced darkening around the edges, and a yellow-green cast. Schaller reported that a day’s work with Claude produced fixes spanning both the kernel sensor driver and libcamera’s software image-processing pipeline.

The problems included incorrect crop handling, a wrongly sized test-pattern register definition, an overly restrictive analog-gain limit, missing lens-shading correction, and a white-balance calculation mixing incompatible numerical scales. He said the white-balance correction applies beyond his laptop to RAW10 and RAW12 sensors.

Schaller has submitted the kernel patches upstream, while Wim Taymans was reviewing the libcamera changes for submission. These were proposed improvements, not a claim that all the fixes had already reached upstream releases.

I fully expect Crider’s and Schaller’s methods to be rapidly adopted by other Linux driver makers. It seriously cuts down on the blood, sweat, and tears programmers need to create drivers for unsupported hardware or to replace second-rate drivers with more fully featured drivers.

As Schaller explained, “The human still decides what to build and checks that it works on real hardware, but the slog shrinks a lot.” Yes, yes it does. I expect this to be a real game changer for Linux desktop device developers.