I own a Brother HL-2140 laser printer. It works fine on Windows. On GNU/Linux and macOS it's a different story: the CUPS driver Brother ships is so broken that any photo you try to print comes out as a mess of scattered dots instead of anything recognizable.
This is an old, well-known problem. People have been fighting with Brother's Linux packaging for this printer for over a decade, swapping in generic drivers like printer-driver-hpijs, patching PPDs, and generally hoping for the best. None of it really fixes the underlying issue, because nobody outside Brother has ever had a clean picture of what the Windows driver is actually doing to the image data before it hits the printer.
The idea
We're deep into the era of genuinely capable AI models now, and that gave me an idea. I have the working Windows driver sitting right there. I have access to Gemini. So why not point a long, detailed prompt at it and ask it to sit down, study the driver, and reverse-engineer the raster format the printer expects.
Reverse-engineering a binary printer driver is exactly the kind of tedious, detail-heavy work that seemed like a good fit for handing off to a model: lots of byte-level pattern matching, lots of hypothesis testing, not much room for shortcuts.
Running the experiment
I wrote out the prompt and let Gemini go to work, half expecting it to either give up or hand me something unusable. Instead it stuck with the problem and came back with a working plan for decoding the driver's output. My job at that point shifted to reading through what it had figured out and turning it into something documented and understandable, rather than doing the raw reverse-engineering myself.
The real test, obviously, was printing an actual photo with it. I ran a print job through the reconstructed driver logic and compared it side by side with what stock CUPS produces on this printer. The difference is not subtle. The CUPS output is the dotted, degraded mess I mentioned earlier. The Gemini-derived driver produces something that actually looks like the source image.
The code itself
I went in bracing for the kind of code you'd expect from an AI asked to reverse-engineer a binary format: a pile of magic numbers glued together with no structure. That's not really what I got. The result was cleaner than expected, though it's still a first pass and there's clear room to optimize and tidy it up further.
Try it
The project is up on GitHub as open-hl2140: https://github.com/behdanisohrab/open-hl2140
If you're stuck with an HL-2140 (or a printer in the same family) on Linux or macOS, or you're just curious how far you can push an LLM on a low-level reverse-engineering task like this, take a look. Issues and PRs are welcome, especially around cleaning up the driver code.
Top comments (0)