無程式碼也能輕鬆打造專業LINE官方帳號！一鍵導入模板，讓AI助你行銷加分！
Claude Code escribió un driver de macOS para una impresora HP que nunca lo tuvo
El 17 de agosto de 2026, un desarrollador llamado Kuber Mehta publicó algo inusual en X: una transcripción completa, ligeramente redactada, de una sesión de 4 horas de Claude Code en la que un agente de IA hizo que una impresora oscura solo-Windows funcionara nativamente desde Cmd-P en macOS — una impresora para la que HP nunca lanzó un driver de Mac.
El post explotó. Luego el repo de GitHub (github.com/Kuberwastaken/hp-laser-1008a-macos) llegó a Hacker News. El hilo de HN entregó lo que HN siempre entrega: una revisión de código adversarial brutal, respondida con una prueba A/B clean-room.
Esta es la historia de esa sesión — y lo que dice sobre agentes de IA haciendo trabajo que solía llevar semanas a ingenieros de drivers.
El problema: una impresora que solo habla Samsung
La HP Laser 1008a es una impresora láser host-based de Samsung rebautizada y barata. “Host-based” significa que es un dispositivo tonto: el ordenador debe rasterizar todo en scanlines comprimidas crudas y empujarlas por el cable en SPL3 (Samsung Printer Language 3 / QPDL v3), un formato propietario.
- Sin driver de macOS — HP nunca lanzó uno para esta familia
- Sin AirPrint — ni siquiera IPP driverless
- Sin PostScript, sin PCL — los drivers genéricos no pueden hablarle
En un Mac con Apple Silicon, el dispositivo está efectivamente muerto. Los intentos previos fallaron todos:
| Enfoque | Resultado |
|---|---|
| PPD genérico PCL/PostScript | CUPS se cuelga para siempre en connecting-to-device |
| splix 2.0.1 (driver SPL open source) | Scanlines rayadas corruptas + páginas en blanco infinitas |
| foo2zjs / foo2qpdl | La impresora imprime una página de error física: SPL ERROR - Please use the proper driver |
El viaje de 4 horas
Paso 1: La trampa del falso offline
Claude añadió la impresora con el driver PCL genérico. El trabajo se colgó en connecting-to-device y CUPS reportó la impresora offline. Excavando con ioreg, Claude encontró el verdadero culpable: la impresora expone bInterfaceProtocol = 4 — IPP-over-USB (modo AirPrint-over-USB). El backend USB crudo de macOS malinterpreta ese byte de estado como “permanentemente ocupado,” atascando el dispositivo en STATUS:BUSY hasta un ciclo de energía.
Paso 2: El muro del sandbox de macOS
En macOS 26, solo los procesos root pueden hablar con interfaces USB crudas — y los filtros de impresión de CUPS están estrictamente sandboxeados, bloqueados del USB crudo por completo. La respuesta de Claude: un script Python independiente a nivel root (direct_write.py) usando PyUSB/libusb para reclamar Interface 0 / Alternate Setting 0 (impresión bidireccional cruda clásica), desacoplar el driver del kernel de Apple, y escribir directamente al endpoint bulk OUT 0x02. Transporte resuelto: 56.738 bytes empujados limpiamente.
Paso 3: La impresora enseña a Claude su propio lenguaje
El transporte crudo no era suficiente — el encoder open source producía basura. Claude compiló foo2qpdl de foo2zjs y la impresora respondió imprimiendo una página de error de autodiagnóstico nítida y legible:
SPL ERROR - Please use the proper driver at POSITION: 0x2000 (8192)
0x2000 es exactamente donde empieza la primera scanline raster comprimida — la impresora parseó las cabeceras PJL pero se atragantó con la compresión. Una segunda prueba a 1200x600dpi produjo Illegal Resolution. El hardware estaba literalmente diciéndole a Claude lo que quería: 600x600dpi, y un encoder que pudiera decodificar.
Paso 4: Contenerizando el códec real de HP
La impresora exigía “el driver adecuado” — que HP distribuye como un binario Linux arm64 (rastertospl) dentro del HP Unified Linux Driver. Claude arrancó Colima (una VM Linux ARM64 ligera para macOS), construyó un contenedor Ubuntu con el rastertospl propietario de HP + libscmssc.so, le alimentó raster CUPS estándar por stdin, y recibió SPL3 genuino compilado por el vendor por stdout. Empujado por direct_write.py — se imprimió una página perfecta.
Paso 5: Conectándolo a Cmd-P (el bypass del socket de CUPS)
El desafío final: el sandbox endurecido de CUPS bloquea a los filtros personalizados ejecutar docker o incluso loguear. La solución elegante de Claude — dividir la arquitectura:
App macOS (Cmd-P)
│
▼
Cola de impresión CUPS (renderiza raster sin comprimir)
│
▼
Backend Socket de CUPS → 127.0.0.1:9108 ← stream localhost bendecido por sandbox
│
▼
hpl1008-daemon (LaunchDaemon root)
│ (transmite raster CUPS por stdin)
▼
Contenedor Linux ARM64 de Colima (hp-spl)
└── rastertospl propietario de HP + libscmssc.so
│ (SPL3 por stdout)
▼
direct_write.py (root PyUSB/libusb, endpoint 0x02)
│
▼
HP Laser 1008a ✅
El backend socket:// JetDirect integrado de CUPS ya está bendecido por sandbox para streams de red a localhost — así que el daemon escucha en el puerto 9108, recibe el raster, lo transmite por el contenedor, y empuja el SPL3 a la impresora. Impresión nativa Cmd-P, segura ante reinicios (LaunchDaemon), entregada como un instalador MIT de un solo comando.
El guante de HN: revisión → A/B test → veredicto
HN entregó su revisión adversarial de marca:
- “splix 2.0.2 arregló esto” — el revisor notó que SpliX 2.0.2 (julio 2026) añadió soporte HP Laser 10x con QPDLVersion 3, paquetes forzados de 512 bytes y una tabla de ancho de banda que imita a Samsung
- Crítica al daemon — el timeout silencioso de 2 segundos para el framing de trabajos es frágil; usa límites de EOF de TCP
- PID USB hardcodeado (
0x069E) — excluye a las hermanas 1003/1006
La respuesta del autor fue la mejor clase de ciencia: una prueba A/B clean-room. Claude compiló splix 2.0.2 nativamente en macOS, verificó que la nueva lógica de ancho de banda se activaba (608 bytes para A4), y alimentó la salida QPDL-v3 cruda por el mismo writer USB.
Resultado: fracaso total. Scanlines corruptas otra vez. La compresión del códec del vendor simplemente no está replicada por los drivers open source — el códec oficial contenerizado era el camino necesario.
Qué significa para el futuro del trabajo de drivers
Esta sesión es un hito genuino para los agentes de IA:
- Leer protocolos del comportamiento del dispositivo — las páginas de error de la impresora se volvieron documentación
- Navegar modelos de seguridad del SO — análisis de sandbox, daemons root, bypasses de socket
- Orquestar toolchains heterogéneas — macOS + VM Linux + contenedor + binarios del vendor
- Iterar con feedback de hardware — páginas físicas como salida de test, ~4 horas de cierre de bucle
Tradicionalmente, esto era semanas de ingeniería de drivers especializada: revertir un formato raster propietario, luchar contra el sandboxing de macOS, y empaquetar un instalador. Un agente, una sesión, una tarde — y publicado bajo MIT para el mundo.
La impresora sigue sin AirPrint. Pero ahora funciona desde Cmd-P en cualquier Mac — porque un agente de IA decidió que “no existe driver” no era una respuesta. 🖨️