A scanner that would not work on Linux led to a method for using AI to record and compare Windows driver behavior and write Linux drivers. Red Hat's Schaller has published three projects and a general-purpose toolkit, hw-harness.
Key points
- What happened: Red Hat's Schaller combined AI with a Windows VM to get a SANE driver working within hours for a Plustek OpticFilm 8200i that lacked Linux support
- Why it matters: He generalized and published the approach as hw-harness, writing drivers solely by observing hardware behavior without copying or disassembling vendor code
- AI's role: AI handles the "tedious middle work" of detecting patterns in thousands of lines of USB captures and generating tests, while humans make design decisions and validate results on real hardware
It started with "hardware that does not work"
As Schaller explained on his blog, the Plustek OpticFilm 8200i he bought had the same product name as the older model, but its controller chip had changed from a Genesys GL845 to a GL128. Linux's SANE scanner framework would not even recognize it. He tried writing a driver with Claude Code, got stuck, and left the project alone for months.
The turning point was a post by Thomas Crider, known in the Linux gaming community as Glorious Eggroll. The developer of Proton GE Custom, a customized version of Valve's Proton Linux gaming compatibility layer, and Nobara Linux described how 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 build the same setup for his scanner.
First, a USB device is passed through to a Windows 11 Pro virtual machine running on KVM, where the vendor's own driver performs an actual scan. Meanwhile, usbmon, the kernel's USB traffic recording facility, records the exchanges on the Linux host below the passthrough layer. The guest OS cannot see that it is being monitored. The same operation is then repeated using the custom Linux driver and captured again with usbmon. Comparing the two traces turns the differences directly into a list of driver bugs.
Joho no Todai confirmed that the README for hw-harness, which generalizes and documents the approach, explicitly states a clean-room policy. It leaves vendor .sys files, the drivers themselves, untouched, collecting only traces, descriptors, INF files, registry data, and ACPI tables. The README says, "If every constant in a driver traces back to a recorded observation, maintainers can merge it." By observing hardware behavior externally rather than copying or disassembling code, the approach deliberately avoids legal risks that could obstruct upstream contributions.
It also handles devices whose buses cannot be intercepted like USB. For devices such as a laptop's internal MIPI camera, where traffic cannot be captured externally, it switches to inspecting Windows-side INF files, registry data, ACPI tables, and device properties.
A scanner, an app, and a laptop camera
Using this approach, the first Linux scan succeeded within hours. A few days later, a nearly complete SANE backend was ready, including infrared scanning support. It supports color, gray, infrared, and color-plus-infrared modes; 300–7,200 dpi; 8/16-bit output; dust and scratch removal using the infrared channel; and exposure multipliers for dense negatives.
While Schaller's work was on hold, support for the scanner had also reached SANE's upstream genesys backend in September 2026. He compared the two drivers. Both resolved the same detail at 3,600 dpi, while full-resolution scanning took 34.6 seconds with Schaller's version and 54.4 seconds upstream. Only Schaller's version supported infrared dust removal, while upstream offered more resolution steps. He cautioned that these were "single-unit, single-frame results, so treat them as one data point," and wrote that he also intends to switch upstream once it reaches feature parity.
A driver alone does not make scanning negatives comfortable. Schaller therefore also developed Negative Vibes, a GNOME app written in Rust. It preserves the scanner's original 16-bit linear data and infrared channel while nondestructively handling negative inversion, film-base correction, dye-crosstalk correction, infrared and software dust removal, IT8 calibration using ArgyllCMS, and TIFF/JPEG/PNG/DNG export. All adjustments are saved as settings layered over the original data, allowing the appearance to be changed and the image exported again later. It is distributed as a Flatpak with the scanner backend included. So far it has been tested on the OpticFilm 8200i. The goal is to support all SANE-compatible film scanners, but that requires a standard mechanism for exposing infrared channels in SANE, which does not yet exist.
The third project fixed the MIPI camera in Schaller's own Lenovo ThinkPad X1 Carbon Gen 14 (Aura Edition). Combining a Sony IMX471 sensor with Intel IPU7, it produced dark images, heavy vignetting, and a yellow-green cast on Linux. He says he began in the morning and had patches for both the kernel and libcamera by the end of the day.
On the kernel side, the IMX471 driver fixes addressed three issues: a crop-selection bug, an incorrect test-pattern register width, and an analog gain cap that was too low, costing about 1.8 stops of sensitivity. In libcamera's software ISP, the fixes addressed entirely missing lens shading correction, which left the edges about 2.7 stops darker, and a bit-depth mismatch in white-balance statistics. The latter fix applies to RAW10/RAW12 sensors generally, rather than being specific to this camera.
In a controlled low-light test, frame brightness rose from 31.1 to 90.9. The red/green ratio moved from 0.890 to 1.047 and the blue/green ratio from 0.672 to 0.823, approaching a USB webcam reference. Schaller attributes the remaining roughly 17% blue deficit in low light to the limitations of gray-world white balance. The kernel patches have been submitted to Kate Hsuan, while Wim Taymans is reviewing the libcamera patches for submission to libcamera.
Taking on the tedious work
Writing drivers for undocumented hardware traditionally meant capturing bus traffic, staring at hex dumps, and forming hypotheses about what each register or control transfer meant. Each hypothesis would be tested individually, repeating the process for weeks. Conceptually simple, it nevertheless required enormous patience and skill.
Schaller says this kind of work suits AI.
It can read thousands of lines of USB capture, notice that a sequence repeats with just one byte changing, and suggest what that byte means. It can write a test to confirm it. And it does not get bored.
Humans decide what to build and check that it works on real hardware, while the painstaking work in between shrinks considerably. Schaller acknowledges that he lacks deep expertise in driver development, writing that he "was able to make progress despite lacking in-depth knowledge of this kind of work."
His observation that reference captures were decisive is also interesting: "Having AI compare a known-good trace against a failing one turns a vague 'it does not work' into a concrete list of differences." For the MIPI camera fixes, the breakthrough came from connecting a USB webcam at the same time and having Claude Code compare the two captures.
2026 has also brought debate on multiple fronts about AI and Linux drivers. The kernel's staging tree adopted a policy of automatically rejecting AI-generated patches (in Japanese); AI identified dead code that prompted the removal of a 27-year-old driver; and a developer who wrote an M4 Mac Mini GPU driver with AI in a month was excluded from Asahi Linux. Where AI modifies existing driver code, quality control and review burdens have become acute issues.
Schaller's method occupies a different position in that debate. Instead of modifying existing code, it observes hardware behavior and writes a new driver from scratch. It neither copies nor disassembles code. AI sits in the middle of a process in which humans provide reference data and validate results on real hardware. Its value lies in letting developers outside their specialty make progress.
When hardware would not work on Linux, the options previously came close to a choice between waiting for support and learning enough to write a driver yourself. Combining hw-harness with AI points to a third path.
Originally published on Joho no Todai. The Japanese original is here.
Top comments (0)