alt Hacker NewsClaude writing a macOS driver for my obscure HP printer built only for Windows
Comments
Unfortunately this is a very misleading article and headline. I don't doubt the end result - it's useful that it works, but it's not "natively" and, unlike what some people assume, Claude didn't write a driver. It basically used HP's existing proprietary driver in a Linux VM on macOS, and just bridged that to macOS.
It also requires a root launcher that runs code from the user ~/.hp1008 dir, so security is weakened.
On a similar experience, I use moonlight on my Android TV to stream video games from my computer in another room. I use my own fork from an unmerged PR which enables me to use an Xbox One Wireless adapter so I can play with my pad wirelessly. These pads have a 3.5mm jack on them which on Windows and Linux enables me to route audio from the game to headphones connected to the pad. Moonlight and the xow driver it bundled, was nowhere near being able to provide this as a feature.
After about 5 hours, feeding it the GIP spec, an export of sniffed usb traffic from Windows, prior art (xone driver for linux), and giving Claude connectivity to my Shield via adb, I had it working. This continuously blows my mind that I dont have to beg a developer on Github to do it for me.
Claude could do it for me for $20.
Wouldn't it have made more sense for Claude to suggest using the existing Linux-Airprint-VM project/product that already does this exact thing?
There's even a zero-install method via https://printervention.app where it runs that Linux VM isolated inside a WebUSB-capable browser. That website itself was posted right here on HN not too long ago.
I get that the LLM code assistant software prefers writing stuff, but constantly re-writing the same solution seems a bit inefficient.
Somehow, I'm not exactly sure why, I got creeped out by Claude's finishing line:
> Thanks for being such a game debugging partner through all the test pages. Enjoy printing, you and the family.
Maybe it's because my own LLM usage is very "Question > Answer" or "Do this > Agent does that" and I never say "Wow, that's crazy it works, thank you!" at the end or such, so I don't see that sort of things, but if I saw that regularly I'd turn me off so badly from using LLMs. I'm not exactly sure where this feeling is coming from though, it's relatively innocent but just feels so inauthentic, I'm guessing because it's simply a machine.
So the critique from the other story holds true - it really is just running the Linux driver inside docker, and (perhaps) dressing it up as something more - though I note the claim on this page is walked back from the original 'writing the driver'. On the other hand, it really did get him printing from his Mac, so in this new LLM results based world we live in it did its job admirably.
Recently, I had bizarre situation: I wanted to play a game from my childhood on Windows 11, but, without changing two booleans in the settings, I could not reliably move my in-game cursor. The catch is that to change those values in the settings, I needed to move my in-game cursor. So I was stuck.
After digging around, I found a file that looked like it could be the settings file, but it was not plaintext.
Naturally, I told Claude all the options I knew existed in the settings and told it what I needed it to change.
After about 10 minutes poking around my system and the file, it correctly identified the bits (not bytes!) that corresponded to the two settings, and flipped them on. It. Just. Worked!
(Well, then I found out I actually needed to do quite a lot more than flipping those bits, but I still found it worth sharing).
I have many more experiences similar to these. LLMs are an amazing superpower.
If this could all finally solve, once and for all, printing and scanning issues it'd be lovely (btw there are entire businesses who's only raison d'etre is "installing printers at clients and fixing them when they stop printing").
But of course it's hard not to both marvel and lament (at) the fact that in the mid-1990s (so yup 30 years ago) I could:
nc 192.168.1.150 9100 < tiger.ps
I know, I know, about garbled print jobs, pages of codes being printed, etc.
But still: it's hard to not at least wonder if some things haven't been lost. For a start printers with their own IP addresses were sweet (instead of a USB cable and, now, people setting up, say, a Pi just to expose a LAN IP for/to their printer). Then of course another talk could be had about the "quality" of modern day HP laser printers compared to what you'd get int the nineties.
I just fix a long standing bug on my Linux desktop I have had for years and kept meaning to look into to see if I could fix. The issue was I have a sound blaster katana sound bar and it works okay but the volume on the device is not in sync with the volume in Linux. In Windows it stays in sync. I can work around it by each time I boot, I press the button to go to max volume, then lower the volume in Linux to the desired level but it's been an annoyance. I described the issue to codex and within a few minutes it had it fixed by updating the pipewire device profiles to use the volume control it exposes. Honestly amazing since I doubt I would have ever gotten around to figuring this out since I didn't even know what level of the stack the issue was, I thought maybe it was in the driver itself.
Four hours of a machine looping through a cycle of repetition, guessing and failure, gratuitous air-punching and premature celebration, before eventually landing on a hideous "solution" that just uses an existing driver from another platform.
LLMs can do stuff but this isn't a good example.
If I understand correctly, it just wraps an existing Linux driver in a container. You can hardly call that writing a driver.
Update: We're actually fully MacOS native now! https://github.com/Kuberwastaken/hp-laser-1008a-macos
Obscure? Sir, the printer is sold on Amazon. It is not obscure.
Claude did not write any macOS driver. It uses the HP Linux driver inside docker. Here is prior art from 2017. In contrast to the AI gibberish, one can understand it:
https://www.alecburton.co.uk/2017/printing-from-a-docker-con...
There are many such tutorials and Claude just plagiarized as usual.
I have actual obscure RGB corner floor lamps with BLE in my office. I had Claude find the BLE protocol and use my Office 365 calendar feed to change their color to red when I'm in a scheduled meeting (event), and back to warm white when the meeting is over, so co-workers know I'm busy without doing "are you busy" sign language through my window. The script is polled every 60 seconds. Tinkering with stuff like this is a lot of fun.
Freedom -- that's what it is. There are now more and more cases where we don't have to ask for permission.
Unfortunately, as I look around, I see most of the hardware vendors around me as gatekeepers. They prevent me from writing custom code in various ways. Apple restricts access to NFC or their UWB positioning, Supernote Manta does not let me access a bluetooth microphone, the list goes on. Denon at least has an API in their amps/receivers: buggy, but it's there.
Claude Code is extremely "honest", and uses that word 10 times in that short transcript.
Update: I saw a bunch of comments on the post asking how I got Claude to do this
I usually answer saying there's not really a hack for it, you just work with it, convey thoughts decently and try out things with educated guesses until it sticks with these projects.
But I actually went ahead and exported the chat in a readable format for anyone curious enough to go through :) https://cdn.kuber.studio/chat/hp-laser-1008a-driver
Thanks for sharing :)
linking this here for those who don't wanna read the threads https://github.com/Kuberwastaken/hp-laser-1008a-macos
genuinely very interesting case to learn from for me because this was one of the HP branded Samsung printers which doesn't have native non-windows support !
I was able to get Claude to write an embedded Rust driver for an unsupported epaper screen in a couple of hours by providing it with the spec and some existing C drivers. It’s still not as fast as the arduino versions, but it let me make progress in a project that I’d been stuck on for months.
Reverse engineering seems like an AI sweet spot.
https://printervention.app (also co-written by Claude) may be useful in similar cases.
If you see articles from old computing magazines or TV shows in the 1980s (there’s some good rabbit holes on YouTube), the prevailing optimism was that everyone would have a computer in their kitchen and write their own programs for whatever they need to do..
But programming languages and operating system fragmentation didn’t let that really take off
Maybe now that original promise of personal computers can be realized :)
Imagine instead of going to the App Store, just telling ChatGPT etc to make a custom app and run it right away on your phone
Along similar lines I used Codex to reverse engineer and build a modern driver for the niche, proprietary Sony USB protocol for an old camcorder I have lying around, having never done anything like that or used Rust before. It feels like LLMs could be a huge force in making older hardware usable again.
Reminded me of when I had a Teletype ASR33 on AirPrint (https://github.com/hughpyle/ASR33/tree/master/cups). With LLMs that would have taken a half hour. It would have maybe been less fun? but there's a lot of time faffing around on PPD that I'll never get back.
I found this bit in the chat log, where the user got an "adverserial LLM" to look at the driver, decidedly humorous:
> This is exactly the kind of feedback worth taking seriously, and it's checkable. [...] But I don't take an LLM's word for it, especially citing specific commits.
My personal experience reversing things relying mostly on Claude or other LLMs is a bit hit and miss. Sometimes it worked great, but sometimes it gets stuck. When it occurs, it kind of sucks because suddenly you have to catch up and assimilate the reverse all in one go if you want to unlock it
Also, having tried my luck recently on an old scanner (Canon 9950f), a word of cautious:
These devices, specially older ones, may not have built-in safety limits in their firmware. In my case, it ended-up only being a few belts rubbing a bit, but it could have been more serious.
Don't let the LLM test stuff unattended, and be ready to pull the plug.
I wasn’t so lucky with my attempt for a Windows 11 driver for an old emaguc MT4 MIDI interface. It works on Macs, but no longer on PCs.
Claude worked for a while and then spun itself into a loop of making a mistake, correcting it, then making it again.
That was 9 months ago so perhaps I should try again.
my Brother dcp-t230 also doesn't have macos drivers and it's a usb only printer. if i ever get some tokens to burn, i would try the same.
I've been having great success with the robots reverse engineering things too. https://github.com/johnboiles/ble-label-printers https://github.com/eastbaymakersclub/pixcut-s1 I've been using Codex in the ChatGPT app for this and it's been really neat to watch it download the vendor's app, decompile it, and make the hardware work.
Awesome. I had a crack at the Xerox Travel Scanner 150, which had niche drivers for some reason, only shipped Windows and didn't make it into SANE. Wireshark and prior art from SANE got me most of the way. Getting the stepper motor working was really hard and I didn't manage to get it completely working Maybe I'll resurrect 15 year when it's a little older. I really fancied a Pi+Scanner pipeline with OCR/AI to file all my documents as they arrive. Maybe I should just take a photo?
Amazed Claude didn't refuse this for "cybersecurity". Then I noticed this was this Opus 4.8? Did the author start with 4.8 or was this a fallback from the 5 series?
I tried to get Copilot to port the Linux drivers for my HP CP1025 to macOS, but it failed. Even modern Linux can’t print to it any more, I had to put an older distribution on a RasPi and now I’m printing at reduced quality.
It was crazy how the LLM held on to outdated information. It suggested so many things that might have worked on an older macOS but very obviously wouldn’t nowadays. It also tried to port from Linux for a while until it eventually discovered that cups on Linux didn’t support that printer either.
Claude is great at that. I have a usb keypad with no linux version of the app to program it. Since its just a vial/qmk based, claude built me a linux version in qt/python.
I've seen this explained as LLMs being well - language models. Driver binaries are just a language understood by the machine executing the binary. While its basically unreadable for normal humans, it is just another language for LLMs & they are able to operate on it, changing the result & translating it (e.g. correlating with specs, logs, docs, etc.).
Given the positive results from what I've heard, this might be actually one are where LLMs could prove useful for once.
Nice! I've an ML-1710 that is sitting in a closet that I'd love to get properly working on macOS. I've tried with SPLIX and followed the directions to the letter to install the drivers, but it just doesn't stick, in that I can only manage to get one print queue through the device for each time the computer is turned on. I gave up and repaired a junked Epson and put that into service, but I really prefer the formar printer for making line tenplates.
Had a similar experience. I bought an ePaper display and a Pi 4 to run a calendar widget on. I got stuck because the open source project I was building off expected the previous generation of ePaper display, and the firmware had changed completely. I found the new firmware examples, but got stuck trying to get it to work. With Claude assisting we banged it out in two sessions of about 3 hours each.
codeberg.org/mjmvisser/infoframe if anyone’s interested.
!!!
If you have MATRIX PRINTER, please consider running GhostScript regression tests per release (twice a year).
The developer is looking for volunteers.
Otherwise upcoming GhostScript version will remove widely used LQ850 driver and you won't be able to use it in the next Debian/Ubuntu/whatever.
https://bugs.ghostscript.com/show_bug.cgi?id=709659
!!!
I'm pretty sure I've used that exact printer on Linux without issue. Long ago, deep into the pre ai era.
Edit: no, I was thinking of the older p1008.
The test printout mentions Samsung ML2010 which had a Mac osx driver (had a Ml2020 till a couple of weeks ago).. by the picture of the printer it seems they had an identical plastic mold..they most likely came from the same oem (xerox).. but still nice from Claude to figure it out..
Nice! About a year ago I used Claude to make a macOS driver for an ancient laser engraver that only ever worked with Windows.
I've had a lot of success (and fun) getting Claude to write a MacOS userland driver for a pointing device (ZSA Navigator).
Yeah. I have a Stratasys J55 3D printer. Industrial and closed.
And now I can print to it via my Mac.
It's a fun time to be alive.
Does anyone know if Apple would actually agree to sign and allow the distribution of such a driver? The vendorid and productid clearly belong to another entity, which could hypothetically want to create their own driver?
I did the same for a scanner that was missing an driver for latest macOS! https://github.com/sylvinus/freethescan
Yeah, it's incredible how we turned something that used to need talent into something you can just pay a big model provider for and have it done for you.
Programming is now easy for anyone to do, no skill needed.
Majority of people are still completely blind to what's going on
I did this at my university, where printing is not supported on Linux. Thanks to Fable, I can now print from my linux laptop and don't pay their ridiculous per-page fee
[dupe] Discussion, including activity from the dev https://news.ycombinator.com/item?id=49344643
This is awesome. I take it your plans for the next weekend include actually cleanrooming the driver so you can skip running it in a linux container? =P
I was able to (through heavy Claude use) successfully reverse engineer a golf cart motor controller that is programmable over USB, but only was supported by a Windows application. Claude walked me through using ILSpy on the .NET assembly, using Wireshark to capture the protocol over USB, and to completely map out all of the functionality in the Windows application. The output was a portable C library and CLI program which, so far, has worked well.
I consider myself kind of an AI detractor but even I'll admit that the tool allowed me to do something it would have taken weeks-to-months to learn to do the hard way.