GNOME developer used Claude to build Linux drivers from Windows traces

Writing a driver for undocumented hardware used to mean weeks of reading hex dumps and guessing what each byte did. Christian Fredrik Kalager Schaller, who works on multimedia at Red Hat and blogs for GNOME, said this week that he used Claude to do that reading, and shipped working Linux drivers for a film scanner and a ThinkPad camera that neither had a Linux driver before.

The method is a shared harness, now at github.com/cschalle/hw-harness. Run the vendor's Windows driver in a KVM virtual machine with the real device passed through. Record the USB traffic on the Linux host with usbmon, which sits below the passthrough layer so the guest cannot see it. Run the same operation on Linux with your own driver, record that trace the same way, and ask the agent to diff the two. The differences are the list of driver bugs.

What the harness shipped

Project one is a SANE backend for the Plustek OpticFilm 8200i, a film scanner using the Genesys GL128 controller that had no Linux support. The upstream SANE genesys backend gained the same scanner in September 2026, so Schaller compared the two. Both resolve the same fine detail at 3600 dpi. His runs in 34.6 seconds at full resolution against the upstream's 54.4, and supports infrared dust removal. He flags both numbers as a single-unit, single-frame result.

Project two is a set of fixes for the MIPI camera in the Lenovo ThinkPad X1 Carbon Gen 14, which uses a Sony IMX471 sensor behind an Intel IPU7. On Linux the camera produced dark images with heavy vignetting and a strong yellow-green cast. The kernel driver returned an error before storing the crop rectangle, so libcamera assumed the full pixel array. The analogue gain cap was too low, costing about 1.8 stops of sensitivity. Lens shading correction was missing in the libcamera software ISP, leaving the corners about 2.7 stops darker. In a controlled low-light test, frame brightness rose from 31.1 to 90.9, and the red-to-green and blue-to-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 percent short in low light, which Schaller puts down to grey-world white balance.

What the agent is good at, in his words

Reference captures are the step that mattered. Giving the agent a known-good trace next to a failing one turns "it does not work" into a concrete list of differences. For the MIPI camera, he connected a working USB camera too so Claude could compare the two captures. The agent is good at the tedium: decoding thousands of lines of USB capture, noticing that a sequence repeats with one byte changing, proposing what that byte means, and writing a test to confirm. The human stays the judge, and every claim is checked on the real hardware.

For a team that owns a device with no Linux driver, this is the first general method with a published harness and measured outputs. The job that used to need a specialist and weeks can now be done in a few weekends: run the vendor driver in a VM, record both sides, feed the diff to a coding agent and verify every proposed constant against the hardware. The limit Schaller names is honest. He does not claim the scanner or the camera is perfect, and he keeps the AI away from writing to the device unsupervised.

Source

• Using Artificial Intelligence to reverse engineer hardware, Christian Fredrik Kalager Schaller, GNOME blog
• hw-harness repository, GitHub