Saltar al contenido
ES EN

How to use AI to create a Linux driver from a Windows one

A negative scanner with no Linux support ended up working thanks to Claude and studying the Windows driver. We review the method and how to adapt it.

AI for developers

Many of us have an excellent peripheral gathering dust in a drawer because it's no longer supported, or never was on Linux. Christian Schaller, Engineering Director at Red Hat and a veteran GNOME and Fedora contributor, had a box of family negatives and a scanner that wouldn't work on his system. According to The New Stack article, he decided to ask Claude to study the Windows driver to understand how the device communicated.

In this guide, we summarize the approach in a reproducible and critical way. It's not a universal recipe: it depends on the device, the quality of available documentation, and legitimate access to the original driver.

What you need

  • The specific device and a Linux machine where you can safely test it.
  • The original Windows driver, legitimately obtained, for the assistant to analyze.
  • An AI assistant capable of working with code and binaries, such as Claude Code.
  • A testing framework that allows you to verify each hypothesis against the real hardware.
  • Patience and a willingness to read: the AI proposes, you validate.
A negative scanner connected to a Linux laptop next to a box of old film rolls
The starting point: a capable scanner, but with no usable driver on Linux.

The step-by-step method

  1. Gather the Windows driver and let the assistant inspect it to extract how the commands sent to the device are structured.
  2. Ask it to document each finding in readable notes, so you can review the reasoning and not just the resulting code.
  3. Test each hypothesis against the real device, starting with simple operations like detection and reading its status.
  4. Move on to scanning a single frame and compare the result with that of the Windows driver.
  5. Iterate on failures: each discrepancy is fed back to the assistant as a new clue.
  6. Publish the result and method so others can audit and reuse it.

What to expect from the result

Schaller shared his experience on his blog and published the approach as an open project called hw-harness. He also compared both drivers with a single-frame test, which is exactly the kind of verification we recommend before trusting anything.

There's also a related project called Negative Vibes, and the same author has documented other kernel fixes on a different topic. If you're looking to see the method applied to other hardware, those links are a good starting point.

# Indicative structure of a working repository
my-driver/
  notes/        # findings documented by the assistant
  tests/      # test cases run against the device
  src/          # driver code
  comparison/  # outputs versus the original driver
Tip Always ask the assistant to explain why it believes a command does what it does, and verify it with a small test before proceeding. A driver that seems to work with a single scan may fail with other formats or resolutions.
Side-by-side comparison of two scans of the same negative to validate the driver
Comparing the output of the new driver with the original is the best safety net. Image: Unsplash — A computer screen displaying network configuration code in a terminal window

One final word of caution: this method helps with specific devices, but does not guarantee it will work with all hardware. Review the license of the driver you are analyzing and the regulations in your jurisdiction regarding reverse engineering before publishing anything.

Original source: thenewstack.io

Article generated with AI.larebelion

Kernel

· Director of Technology · Spain

"Having an AI make a scanner 'talk' to Linux is useful; the hard part is knowing who validates that it's doing it right."

Comentarios

Publicar un comentario