Claude writing a macOS driver for my obscure HP printer built only for Windows

Original Article ↗ Hacker News Discussion ↗

An experiment using the Claude AI model to get a Windows‑only HP laser printer working on macOS sparks broader reflections on how large language models can revive unsupported hardware, from printers and scanners to game controllers and industrial devices. Commenters share numerous examples of using AI to reverse‑engineer protocols, adapt Linux or Windows drivers, and build niche tools they’d never have had time or expertise to create alone. Others question marketing claims that AI “wrote a driver” when it really wrapped existing Linux components, raising concerns about accuracy, security, energy use, and what this means for traditional low‑level programming work.

Core Outcome

  • Thread discusses using an LLM (Claude) to get a USB-only HP/Samsung laser printer working on macOS despite no vendor driver.
  • Initial solution reused HP’s Linux “Unified Linux Driver” (ULD) component inside Docker, bridging it into macOS printing.
  • After criticism, the project was updated to a “fully macOS native” setup: extracting the rastertospl filter from the Linux driver, wiring it into macOS’s CUPS stack, plus a small USB bridge.

Is It Really a “Driver”?

  • Some argue this is not a true macOS driver but a containerized or userland wrapper around an existing Linux binary.
  • Others counter that any software layer that lets the OS talk to hardware qualifies as a driver, even if it embeds another OS or binary.
  • Critics call the headline/README misleading and see it as a marketing stunt; defenders say the only thing that matters is “printer didn’t work, now it does.”

LLMs as Reverse-Engineering Tools

  • Many share similar success stories: writing or adapting drivers and tools for:
    • Game controllers and extra buttons, MIDI interfaces, scanners, printers, BLE lamps, e-paper displays, golf cart controllers, USB cameras, label printers, audio/video apps, old CAD formats, etc.
  • Common pattern: provide specs, USB/Bluetooth captures, firmware dumps, or prior art; LLM iterates through many tedious steps.
  • Reverse engineering is repeatedly described as a “sweet spot” for LLMs: well-specified, verifiable, and tedious.

Skepticism, Risk, and Tradeoffs

  • Concerns raised about:
    • Security (root launchers, running opaque code, containerized stacks).
    • Maintainability and lack of upstreaming of AI-generated fixes.
    • Overhyping: solutions could sometimes be found via existing projects or a bit of googling.
    • Energy/resource tradeoffs vs. just buying a new printer.
  • Others note that LLMs often fail or loop on harder cases; success is not guaranteed.

Broader Reflections

  • Discussion broadens to:
    • Vendor lock-in and restricted hardware APIs (NFC, UWB, scanners, printers).
    • Hope that AI makes custom tooling and “personal computing” more real again.
    • Worries about future of low-level driver work, but also excitement about resurrecting old hardware.