top | item 32838225

Ask HN: How do I write a Linux driver for my 15 year old photo printer?

254 points| pushedx | 3 years ago

I'm interested in writing a x86_64 Linux driver for my 15 year old photo printer.

It looks like someone out there maintains 32 bit drivers for this printer, but I'd like low-hassle native support for my 64-bit install.

https://askubuntu.com/questions/1324015/how-to-install-print...

Where do I get started with this? What's the toolchain for sniffing USB data and that sort of thing?

104 comments

order
[+] fuckstick|3 years ago|reply
This is an extremely poor venue for this type of question - the answers are all over the place and mostly unhelpful (printer drivers in Linux almost never involve a custom kernel driver). You might have better luck on Arch Linux forums of all places.

What you’re asking for probably won’t be low hassle compared to just running the 32 bit usermode “driver” - which should run fine on a 64 bit system with some packaging help.

Ask yourself, are you trying to use the damn printer or you want a possibly educational rabbit hole to go down. Even if you sniff the USB (you can simply use pcap/wireshark) what are you expecting to see? It will likely be Canons proprietary raster and control format. Reversing that from the bus alone will be an enormous amount of work. I’ve written proprietary “WinPrinter” printer drivers with the spec in hand and it’s still not trivial.

[+] jrockway|3 years ago|reply
This is the best advice I've read so far. I think that it's good to separate "I need a hard copy of a document I have" with "I'd like to learn how to reverse engineer proprietary hardware". If you need a hard copy of a document, just email the thing to Kinkos and be done. If you want to start reverse engineering stuff, I'd get the "forward engineering" down first. Get a USB-capable arduino, try making a rotary encoder attached to it into a Linux input device. Make it show up as a device you can write 3 bytes to and turn the onboard LED that color. If you really want to crawl before you walk, skip USB and attach these things to a Raspberry Pi or similar. (Linux has built in drivers for all of these things, amazingly!) Now you have the basics of the communication down, and you can consider looking at wading into the undocumented archana of a proprietary one-off printer. It's going to be a really big project even for someone who has designed a printer and written a driver for it.

That said, sniffing and replaying packets might get you pretty far. You should be able to do basic things like making the windows driver eject a piece of paper, and then doing that from Linux.

[+] rroot|3 years ago|reply
I really don't agree with this.

What we have here is an enthusiastic hacker wanting to go down the rabbit hole of writing a hardware driver. That's no easy task (like you point out), and answers like this are not helpful at all.

The answer is discouraging and seem to only sow doubt in OPs mind. Let him find out how hard it is. May I remind that this website is called "Hacker News".

Let the voting suggest the venue for the question - it hit the front page of hacker news.

[+] AshamedCaptain|3 years ago|reply
I mentioned to just use the Gutenprint mailing list, but I was downvoted. They are at least a bit more likely to minimally look at the proprietary driver (no one of the commenters here did), or even remember by heart a similar model with the exact same interface (which is rather likely to exist).
[+] dopamean|3 years ago|reply
I love how "Hacker"News threads has evolved to the point of actively discouraging people from hacking.
[+] matheusmoreira|3 years ago|reply
> you want a possibly educational rabbit hole to go down

What would your advice be if we assume that was what the author wanted? I had a lot of fun reverse engineering my laptop's keyboard LEDs and I'd love another rabbit hole to go down into...

[+] a-dub|3 years ago|reply
wireshark/pcap/scapy

last i played with this, i had to hack up scapy to handle the windows usb packet capture format. (windows and linux usb packet captures are/were in different formats, unfortunately)

when you're on windows you should print a bunch of images and then try and train a transformers neural network to predict the packets from the images alone.

if you got this to work, it would be cool.

[+] yyyk|3 years ago|reply
Modern printers usually work one of two ways: You can feed them directly a typical printer language (PostScript, PCL or PDF), or you work with CUPS PPD files. Both are userspace.

It would be easiest to see if there's a PPD for closely related printer* - most manufacturers reuse components and/or evolve them incrementally - and start modifying stuff from there. There's a decent chance it would already work for basic functionality, and that you'll be able to improve it by trial and error. If you are lucky, you may be able to get a decent driver without even needing to bother with USB sniffing.

* e.g. A similar Canon printer by model name.

[+] pessimizer|3 years ago|reply
> Modern printers usually work one of two ways

Are 15 year old photo printers modern?

[+] zamalek|3 years ago|reply
You might the PPD in a Windows installer.
[+] btdmaster|3 years ago|reply
AUR package: https://aur.archlinux.org/packages/cnijfilter-ip1800series (Arch uses PKGBUILDs, which are roughly bash shell scripts: https://wiki.archlinux.org/title/PKGBUILD)

If you read https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=cnijf..., you should be able to compile the 32-bit driver yourself and try and port stuff from there, but note that only parts of the driver are GPL2 and some are proprietary, and it's not entirely obvious which is which (though, from the looks of it, the prebuilt libraries are proprietary and everything with Makefile.am and autogen.sh is GPL2)

[+] frankjr|3 years ago|reply
> Arch uses PKGBUILDs, which are roughly bash shell scripts

They are Bash scripts.

[+] mmastrac|3 years ago|reply
The printer driver appears to be 100% userspace, so you can more than likely use QEMU in userspace mode to run the driver on any system:

https://www.qemu.org/docs/master/user/main.html

[+] kelnos|3 years ago|reply
If it's an IA32 binary and the system is x86_64, you don't even need qemu; 64-bit Linux can run 32-bit binaries natively. You just need to install the 32-bit versions of any library dependencies (trivial on something like Debian, where the packaging system supports doing this out of the box).
[+] chpatrick|3 years ago|reply
Maybe it's easier to add it to Gutenprint? http://gimp-print.sourceforge.net/

It supports Pixma ip2000, so maybe it's not a huge change.

This describes how to add a new printer: http://gimp-print.sourceforge.net/reference-html/c199.html

[+] nixcraft|3 years ago|reply
RMS started open source because of printer driver issues (he wanted the source code but wasn't allowed it and thought it as a betrayal of the hacker culture). This post is like history repeating itself.
[+] kristopolous|3 years ago|reply
It's interesting. Primary source documents from the 1980s really talk about it as a debacle between Symbolics and Lisp Machines Inc, Stallman being caught in the middle and then deciding they were both bad.

While on the other hand, contemporary accounts date it to a Xerox 9700 printer at MIT in 1980.

I don't know. You could say in the 1980s the printer story sounded too absurd so they emphasized the clash of Titans aspect or you could say that we really like provincial origin stories these days so this "a simple motivated man with a great idea" framework is more appealing

This kind of stuff is fascinating; how history is narrated differently throughout time

For people uninitiated, the idea is materially, only discrete events happen. Stories are the narrative sense making humans project on them.

[+] pessimizer|3 years ago|reply
We can blame RMS for inspiring business to react to him with Open Source, but he started Free Software.
[+] antegamisou|3 years ago|reply
Grab a copy of Linux Device Drivers by Jonathan Corbet, Alessandro Rubini, Greg Kroah-Hartman:

https://lwn.net/Kernel/LDD3/

Don't mind the document's age, the principles have largely remained unchanged. Besides, it's probably a better fit since you're targeting a device from 2007

I understand this may be kind of non-specific to what you were expecting, but it's the most rewarding way of achieving what you want and coming up much faster with a driver for an obscure device next time.

[+] fuckstick|3 years ago|reply
Unfortunately, it’s completely irrelevant to the question asked as printers are typically not driven by kernel mode device drivers.
[+] sireat|3 years ago|reply
A quality book, recommended.

I do remember having a bit of trouble finding the most recent source code for the book at the time (which was 12 years ago).

[+] rroot|3 years ago|reply
Small rant, although on topic.

I once had to ditch a perfectly functioning scanner (HP), due to out-of-date drivers and no linux support. I now do my best to always buy hardware that I know is well supported on Linux.

For example, some CanoScan scanners are completely supported by Sane, see http://www.sane-project.org/lists/sane-mfgs-cvs.html

[+] jandrese|3 years ago|reply
My old CanoScan is only supported by Linux now. The last set of drivers they released were for Windows 7 32-bit only. The Mac drivers also stop at a similar vintage and are not forward compatible. Sane is the only remaining option.
[+] brudgers|3 years ago|reply
For what it's worth, fifty bucks solved my Linux photoprinter driver problem (Canon Pro100). [1]

I bought Turboprint. https://www.turboprint.info/

To me, it is the shortcut that will save endless searching for something that doesn't exist.

My free all Linux based solution was driverless printing, but it has limitations.

My non-Linux exclusive solution was an old Thinkpad running windows and SD card sneakernet. That was the simplest thing that might work so I tried it first.

Good luck.

[1] Well mostly solved it...I mean it solved all the important issues with a color managed workflow. At the scale of color managed workflows, $50 is about rounding error on X-rite gear...or even Datacolor gear. Never mind if you price your time.

[+] torstenvl|3 years ago|reply
I've never written a kernel driver, but wouldn't it be easier to start with the 32-bit driver, update the kernel APIs, and move (most?) integer types to fixed-width?
[+] hapless|3 years ago|reply
Printer drivers are user space.
[+] raverbashing|3 years ago|reply
That's exactly it

(not sure if the kernel USB API is the same, that might be a tricky part)

[+] lallysingh|3 years ago|reply
These folks seem to have a 64-bit linux driver for it, for $49 eur: https://www.turboprint.info/
[+] digitallyfree|3 years ago|reply
Unless there's a specific reason for using this printer the unit itself is worth far less than 49EUR. There are used models that can be had for cheap with full Linux support.

Now writing or reversing a Linux driver for the printer though can be a fun project but I personally wouldn't buy this driver just so I can use the printer.

[+] triggercut|3 years ago|reply
There was a really good article posted the other day here, and while focusing on windows, gives a lot of interesting tips for investigating the history of how the driver package was put together and who wrote the driver and using that to help.

https://news.ycombinator.com/item?id=32714806

[+] hapless|3 years ago|reply
Canon devices usually support PCL and Postscript.

The proprietary drivers are just faster/fancier.

[+] bgorman|3 years ago|reply
Even the low end devices? Doesn’t postscript cost an arm and a leg to license?
[+] lifeisstillgood|3 years ago|reply
Thank you for posting this here. I have managed to get bogged down just replacing my home router with OpenWRT version (I blame lack of time) so while I cannot give you any useful tips, I can celebrate your bravery (or time management skills) and wish you all the very best.

The site is Hacker News, so we need a bit more low level hackery here, and a few less insights into ideal product management style.

[+] MisterTea|3 years ago|reply
Printers are odd beasts. At first glance they appear to be a bitmap printing engine for paper (or whatever the medium) and you send it a bitmap and maybe some settings. But no, they actually have a front end computer that speaks one or more page layout languages. That language tells the printer how to render the data into bitmap which is printed.

You first have to figure out which language your printer speaks. If it speaks a common language like postscript (basis for PDF) or PCL (printer command language) then you might be able to use a generic driver or one from a similar printer. If it is proprietary you will need to reverse engineer it by installing the printer in a native environment along with tools to sniff/log the communications send some test prints with magic data and figure out the command language that way.

Given that your printer already has a 32 bit driver it stands to reason you could have a look at the 386 source and see what fails to build on an amd64 machine. Then correct that and you have a driver.

[+] userbinator|3 years ago|reply
I'm not familiar with the exact model in question, but photo-oriented (as opposed to text-oriented) printers are usually bitmap-only, especially the cheaper ones.

The main problem is that the format is not documented, and there may also be a layer of compression.