Red Hat Engineer Uses Claude and Custom Harness to Reverse-Engineer Linux Drivers

Christian Schaller · Linux Drivers: Christian Schaller used Claude Code to build Linux drivers for unsupported hardware.

Faced with hardware lacking native Linux support, Red Hat engineering director and GNOME contributor Christian Schaller turned to AI-assisted development. By pairing Claude Code with a customized virtual machine harness, Schaller successfully reverse-engineered Windows drivers to bring functionality to an unsupported film scanner and a laptop camera, subsequently releasing the underlying methodology as an open-source project called hw-harness.

Reverse-Engineering the Plustek Scanner and Building Negative Vibes

Schaller originally purchased a Plustek OpticFilm 8200i scanner to digitize family negatives, only to discover a silent chipset swap to a Genesys GL128 that lacked a recognized Linux driver. Inspired by a post from Tom Crider on X regarding AI-driven mouse driver fixes, Schaller established a KVM virtual machine workflow. According to both source accounts, Claude operated the Windows manufacturer software inside the VM while `usbmon` captured traffic on the host Linux side. By diffing the Windows USB traces against the experimental Linux implementation, Claude identified protocol discrepancies and rapidly generated a working backend.

Although upstream SANE community developers independently added support for the newer 8200i chipset around September, Schaller’s custom driver offered distinct advantages, including infrared dust removal and faster single-frame execution times in initial tests. To accompany the hardware work, Schaller utilized Claude to write an auxiliary Rust-based GNOME application named Negative Vibes. The utility preserves original 16-bit scan data and the infrared channel, layering non-destructive adjustments, ArgyllCMS color calibration, and multi-format exports on top.

Fixing the Lenovo ThinkPad Camera with Configuration Files

Buoyed by the scanner project, Schaller targeted the internal MIPI camera on his Lenovo ThinkPad X1 Carbon Gen 14 Aura Edition, which suffered from dark images, severe vignetting, and a yellow-green cast under Linux. Because the camera lacks a traditional USB bus to tap, Schaller fed Claude configuration files, Windows registry entries, ACPI tables, and INF files. By also connecting an external USB webcam as a reference point for comparison, Claude located and resolved several critical driver flaws.

The resulting patches addressed a crop-selection bug, an incorrectly defined test-pattern register, and an overly restrictive analog gain cap that had severely limited sensor sensitivity. Additional fixes targeted libcamera's software image signal processor, correcting missing lens-shading corrections and white-balance calculation mismatches. Schaller noted that the patches have been submitted for community review, with Nvidia's Kate Hsuan handling kernel changes and Red Hat's Wim Taymans overseeing libcamera adjustments.

Implications of AI-Driven Hardware Harnesses for Linux

The introduction of the hw-harness project under an MIT license highlights a significant shift in how developers might approach the notoriously tedious task of writing drivers for undocumented hardware. Historically, reverse-engineering hardware required weeks or months of staring at hex dumps, manual USB capture analysis, and tedious trial-and-error hypothesis testing. By automating the comparison between a vendor-supported Windows virtual machine and an open-source host implementation, AI coding agents can shoulder the repetitive burden of data decoding and constant cross-checking. This lowers the barrier of entry for developers attempting to bridge hardware manufacturer gaps on minority operating systems like Linux, potentially expanding hardware accessibility for users who encounter unsupported peripherals. At the same time, this methodology introduces important practical and editorial limitations. As Schaller's own experience with the Plustek scanner demonstrates, duplicated community efforts can occur concurrently, raising questions about redundancy when independent developers race to solve the same hardware deficits. Furthermore, AI-generated patches still require rigorous human verification, physical testing, and formal upstream code review—evidenced by the ongoing review process involving kernel and libcamera maintainers. Licensing questions regarding how data is extracted from vendor files, coupled with the fact that the generalized harness has not yet been tested across a broad array of distinct hardware configurations, suggest that AI-assisted driver development remains an experimental proof-of-concept rather than an automated silver bullet for the Linux ecosystem.

Editorial graphic and headline text by Signal Titans.

Source: His scanner wouldn’t work on Linux — so he let Claude study the Windows driver · Using Artificial Intelligence to reverse engineer hardware | Christian F.K. Schaller

Share this article
FacebookThreadsLinkedInX

Leave a Reply

Your email address will not be published. Required fields are marked *