AI Watches Windows Drivers to Write Linux Drivers: A Red Hat Developer's New Reverse-Engineering Approach

It Started with a Scanner That Wouldn't Work

A common frustration for a Linux user: they bought a Plustek OpticFilm 8200i film scanner, plugged it into a Linux machine, and it wasn't recognized at all. Red Hat developer Schaller ran into this typical problem: the product name was the same as an older model, but the controller chip had changed from the Genesys GL845 to the GL128, and the SANE scanning framework had no idea what it was. He tried writing a driver with Claude Code, failed, and shelved the project for months.

The turning point came from a post by Thomas Crider (known in the Linux gaming community as Glorious Eggroll, developer of Proton GE Custom and Nobara Linux): he had an AI agent control a Windows virtual machine to fix a mouse driver. Schaller pasted the post into Claude Code and asked it to set up the same environment for his scanner.

SANE (Scanner Access Now Easy) is the de facto standard scanner access framework on Linux and Unix-like systems. Its architecture is split into a frontend (user interface programs like simple-scan and XSane) and a backend (driver libraries that communicate directly with specific hardware). The backend exposes scanning, parameter configuration, and image acquisition capabilities to higher layers through a unified API, so when a backend for a given scanner hasn't been implemented or doesn't cover its new hardware, applications won't find the device even if they launch. genesys is a well-known SANE backend responsible for scanners using Genesys Logic chips, supporting a large number of Plustek, Canon, Epson, and other models built on that vendor's chips. Because different production batches can keep the same model name while swapping the controller chip, the backend must implement register operations, timing control, and data parsing chip by chip — which is a common reason new chips go unsupported for long stretches.

The Core Mechanism of hw-harness

The infrastructure behind this method is a USB device passed through to a Windows 11 Pro virtual machine running on KVM, letting the vendor's own driver perform a real scan operation. Meanwhile, the Linux host captures all data exchanges crossing the passthrough layer via usbmon (the kernel's USB traffic recording facility) — the system inside the VM has no idea it's being watched. Then the same operation is repeated with a custom Linux driver, again recorded with usbmon. Comparing the two traces turns the differences directly into a list of driver bugs.

Schaller generalized this method and released it as the hw-harness toolkit. According to confirmation by Joho no Todai, its README explicitly states a clean-room policy: no touching the vendor's .sys file — that is, the driver itself — and only collecting trace data, descriptors, INF files, registry data, and ACPI tables. The README says: "If every constant in the driver can be traced back to a recorded observation, a maintainer can merge it." By observing hardware behavior externally rather than copying or disassembling code, this method deliberately sidesteps the legal risks that could block upstream contributions.

For devices like MIPI cameras where bus traffic can't be intercepted externally, the method switches to inspecting the Windows-side INF files, registry data, ACPI tables, and device properties.

usbmon is a USB traffic monitoring facility built into the Linux kernel, exposing an interface through debugfs or sysfs, and can record URB (USB Request Block, the kernel's basic data structure describing a single USB transfer) per bus and device without modifying the device driver. Every control, bulk, or interrupt transfer's request type, endpoint address, data payload, and completion status is captured, so the protocol dialogue between host and device can be fully reconstructed. KVM, or Kernel-based Virtual Machine, works with QEMU to provide hardware virtualization, and through mechanisms such as VFIO it passes through physical USB controllers or individual USB devices to the guest, allowing the Windows driver inside the VM to exclusively operate the real hardware while the host-side usbmon can still see all packets flowing through that device — creating an observation setup where "the device runs on the VM and the traffic is recorded on the host."

Three Projects Prove the Method Works

SANE scanner driver. With this approach, the first Linux scan succeeded within hours. A few days later a nearly complete SANE backend was ready, including infrared scanning support: color, grayscale, infrared, color-plus-infrared modes; 300–7,200 dpi; 8/16-bit output; dust and scratch removal using the infrared channel; and exposure multipliers for high-density negatives. Schaller compared his driver with an implementation that entered the SANE upstream genesys backend in September 2026: both resolved the same detail at 3,600 dpi, and a full-resolution scan took 34.6 seconds with Schaller's version versus 54.4 seconds with the upstream version. Only Schaller's version supports infrared dust removal, while the upstream version offers more resolution steps. He cautions that this is a "single-machine, single-frame result — treat it as one data point," and says he plans to switch once upstream reaches feature parity.

The Negative Vibes application. A driver alone isn't enough to scan film comfortably. So Schaller developed Negative Vibes, a GNOME application written in Rust that preserves the scanner's raw 16-bit linear data and infrared channel, and non-destructively handles negative inversion, film base correction, dye crosstalk correction, infrared and software dust removal, ArgyllCMS-based IT8 calibration, and TIFF/JPEG/PNG/DNG export. All adjustments are layered as settings on top of the raw data, so the look can be changed at any time and re-exported. It's distributed as a Flatpak with the scanner backend built in. So far it's only been tested on the OpticFilm 8200i, and the goal is to support all SANE-compatible film scanners — but that would require a standard mechanism in SANE for exposing the infrared channel, which doesn't yet exist.

ThinkPad MIPI camera. The third project fixed the MIPI camera on Schaller's own Lenovo ThinkPad X1 Carbon Gen 14 (Aura Edition) — a Sony IMX471 sensor paired with an Intel IPU7 — which produced dark images, severe vignetting, and a yellow-green cast under Linux. He says he started in the morning and by the end of the day had patches for both the kernel and libcamera. The kernel-side IMX471 driver fixed three issues: a crop selection bug, an incorrect test mode register width, and an analog gain cap that was too low (losing about 1.8 stops of sensitivity). The libcamera software ISP side fixed completely missing lens shading correction (edges were about 2.7 stops dark) and a bit-depth mismatch in the white balance statistics, which applied to RAW10/RAW12 sensors rather than being specific to this camera. In a controlled low-light test, frame luminance rose from 31.1 to 90.9, the red/green ratio went from 0.890 to 1.047, and the blue/green ratio from 0.672 to 0.823, approaching USB camera reference values. Schaller attributes the remaining roughly 17% blue shortfall in low light to the limitations of gray-world white balance. The kernel patches have been submitted to Kate Hsuan, and the libcamera patches are under review by Wim Taymans.

MIPI refers to a series of specifications set by the Mobile Industry Processor Interface Alliance, of which MIPI CSI-2 is a commonly used serial image transmission protocol between cameras and processors, widely used in laptop built-in cameras, phones, and embedded devices. Unlike USB cameras, CSI-2 typically doesn't travel over a USB bus that generic tools like usbmon can directly capture; the link is often inside the SoC or connected through a dedicated receiver, making it physically difficult to simply tap and sniff the way USB allows. So the "record bus traffic then compare" path can't be used, and the method falls back to interpreting static configuration information on the Windows side — INF, ACPI, registry — to infer register write sequences. A software ISP (Image Signal Processor) moves processing traditionally done by dedicated hardware — lens shading correction, white balance, demosaicing, color matrices — onto the CPU in user-space frameworks like libcamera. If its parameters or bit-depth assumptions are wrong, the result shows up as dark images, color casts, or vignetting — exactly the class of problems fixed in the ThinkPad camera case.

AI Handles the Middle Grunt Work, Humans Make Decisions

Writing drivers for undocumented hardware traditionally means capturing bus traffic, staring at hex dumps, forming hypotheses about what each register or control transfer means, then testing one by one, over and over. Conceptually simple, but requiring enormous patience and skill. Schaller believes this kind of work suits AI.

"It can read thousands of lines of USB capture data, notice that some sequence repeats with only one byte changing, and hypothesize what that byte means. It can write tests to confirm it. And it doesn't get bored."

Humans decide what to build and verify results on real hardware, and the grueling middle stretch is dramatically shortened. Schaller readily admits he lacks deep expertise in driver development, writing that he was able to "make progress despite lacking deep knowledge of this kind of work."

His observation about the decisive role of reference captures is equally interesting: "Having AI compare a known-good trace against a failing one turns a vague 'it doesn't work' into a concrete list of differences." The breakthrough on the MIPI camera fix came from connecting a USB camera at the same time and having Claude Code compare the two captures.

A Different Position in the AI-and-Linux-Drivers Debate

The 2026 debate over AI and Linux drivers has unfolded on multiple fronts: the kernel staging tree adopted a policy of automatically rejecting AI-generated patches; AI identified dead code that led to the removal of a 27-year-old driver; and a developer who wrote an M4 Mac Mini GPU driver in a month using AI was excluded by Asahi Linux. When AI modifies existing driver code, quality control and review burden have become acute problems.

Schaller's method occupies a different position in this debate. It doesn't modify existing code — it observes hardware behavior and writes a new driver from scratch, neither copying nor disassembling code. AI sits in the middle of the process, with humans providing reference data and verifying results on real hardware. Its value lies in enabling developers outside a specialty to make progress.

When hardware doesn't work on Linux, the choice used to be roughly between waiting for support and self-teaching until you can write a driver. hw-harness combined with AI points to a third path.

Clean-room is a legal convention in software and hardware reverse engineering used to separate "understanding" from "implementation": one group analyzes the original product or binary and writes a specification, and another group implements from scratch based solely on that specification, ensuring the final code contains no copyrighted or trade-secret-protected expression and reflects only unprotected functional and interface facts. In the driver development context, vendors' .sys files, firmware, and documentation are typically released under proprietary licenses, and directly disassembling and translating their logic can trigger licensing or copyright disputes and cause upstream communities to reject merges due to legal uncertainty. Schaller's method emphasizes that every constant can be traced back to a recorded external observation (such as bytes in a USB message), limiting the source of knowledge to publicly measurable hardware behavior. It should be noted that this reduces rather than completely eliminates risk; issues like patents on the hardware interface itself and firmware redistribution may still exist independently.

One-line Summary

A developer uses AI to compare Windows and Linux USB traces, writing drivers for unsupported hardware in hours.

Paragraph Summary

Red Hat developer Schaller found a new path for a Plustek film scanner that Linux couldn't recognize: pass the USB device through to Windows 11 in KVM, let the vendor driver perform a scan, capture all USB traffic on the host with usbmon, then repeat the operation with a self-built Linux driver and turn the differences between the two traces into a concrete bug list. He generalized the method into hw-harness and follows a clean-room policy of only observing external behavior and never touching the vendor's .sys files. Claude Code handles the middle work of finding patterns in thousands of lines of captures and generating tests, while humans handle design and real-hardware verification. Three projects validated the results: a first successful scan within hours leading to a nearly complete SANE backend, the Rust/GNOME application Negative Vibes, and kernel and libcamera patches fixing a ThinkPad MIPI camera.