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.
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.
> Make it show up as a device you can write 3 bytes to
I've been curious about doing something like this for a while, but don't even really know where to start when it comes to researching information on this topic. Do you have any good resources for accomplishing this?
With existing USB devices you don't usually need to go nearly this low level to reverse engineer them - just enumerating the endpoints and then using Wireshark and USB packet capture is plenty sufficient.
Understanding how the USB wire protocol works is definitely valuable knowledge in some arenas, but not at all important for the kind of reverse engineering task OP is trying to perform, as they can generally speaking trust the electrical layer is standard and only need to operate at a level above it.
Same for the "write 3 bytes to a USB device" hypothetical from upthread - electrical understanding of USB is interesting but ultimately unimportant if you're using an existing USB stack - higher level knowledge of USB endpoint types and transport mechanisms is the name of the game there.
If I were given this task and I had to produce a driver with source code (rather than just get things working), I'd start with a combination of USB sniffing and static decompilation (Ghidra/IDA) of the Canon binaries, followed by perhaps some dynamic analysis (logging shims) if things turned out very complex.
If I just had to get things working, I'd just use one of the many approaches to mix 32/64-bit userland binaries in order to shim the 32 bit Canon binaries into a 64-bit CUPS driver.
So most Arduino-alikes have USB support these days, and often appear to the host computer as a serial port. The absolute easiest thing is to take advantage of this; on the microcontroller end read the color over the serial port and set the LED appropriately. On the host computer end, write a tiny program that opens the right serial port and sends the desired bytes. Super straightforward.
From there, being a USB HID device will be a lot easier on your host machine code. You have to speak a predefined protocol, but the OS can use its own drivers to take advantage of the functionality you offer. For example, your microcontroller code can be a keyboard or a joystick. (It's still bidirectional, so you should be able to configure the color of the on-board LED. I don't know whether or not there's a standard there so you can just use a pre-written host app across platforms.)
Finally, if you want to pick apart an actual product that does this, I just found: https://www.blinkstick.com/
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.
> While normally I would agree with your comment, printers are an especially complicated class of device.
I think it is far worse than that. Printers are commodity products and pretty cheap for what you get new for hundred to a few hundred bucks, which is a hardware and software package that is likely to work flawlessly out of the box and for at least a few years. Labor is not cheap. There was a threshold crossed 20-25 years ago where it no longer made economic sense to repair hardware, and ever since the broken is simply replaced. Even if this printer technically works, if the 32-bit driver is unacceptable, then it classifies. The amount of effort required compared to the value of the product is staggering. Add to this that it already works, albeit with a 32-bit driver, and we're entering the territory of mental illness; perfectionism and obsession are not virtues, they are symptoms.
OP is not a hacker, but rather is attempting to Tom Sawyer a hacker into painting his fence for him. Hackers are notorious for ugly solutions and would not ever whine about using a 32-bit driver, nor do they ask for all the work to be done for them. What possible realized benefit of having a 64-bit driver for this printer is not exactly clear. It has the memory that it has, 128MB, and a driver capable of 4 billion times the address space should make absolutely no difference, because the memory is what it is.
The top reply is apt, and the GP is only encouraging heartache, disappointment and failure. If the OP wants a 64-bit driver, he'll need to find a replacement printer that comes with one. Conversely, he can earn a computer engineering degree and go to work for a few years in the device driver industry to get the experience necessary to approach and solve this tiny problem requiring massive knowledge for pretty much no benefit. I would recommend instead meditating on why it is difficult to impossible to change the nature of something and/or why you shouldn't build your castle in a swamp.[1]
As someone who has hosted an email server and done calculus, it’s way harder.
Email servers have whole scripts and instructions and tutorials on how to run them with a completeness that is surely missing from this printer. Calculus has whole libraries full of instructional books.
It’s probably similarly hard to learning bash and Linux and networking and c and writing an email server from scratch with only the SMTP spec in hand or learning all of calculus by being told simply that you can calculate the slope of a line and being handed a slide rule.
(That’s how my professor taught calculus btw. It sucked)
considering that you'd need to know calculus, linear algebra, and other disciplines of math to be able to build some of the image, vectoring, and rastering logic... yes.
Sad to see that on "hacker" news the top-post is essentially, go to kinkos. I am legitimately interested in the understanding the scope of the work and what it would entail to solve such a problem successfully. And, maybe I only have enough resources to solve the elementary steps but that's beside the point.
Also, this is a relatively new post so maybe relevant information will eventually bubble up. I am starting to see some interesting comments.
> Sad to see that on "hacker" news the top-post is essentially, go to kinkos.
"Essentially" is essentially dishonest here. The top post says:
1. HN is not the best venue to get help for this.
2. The answers that you have gotten so far are mostly bad.
3. Printer drivers in Linux almost never involve a custom kernel driver.
4. The Arch Linux forums would be better for this question.
5. Running the 32 bit driver might be easier than writing a 64 bit driver.
6. You might need some packaging help to run the 32 bit driver on a 64 bit system.
7. This would probably only be a worthwhile project only if you were trying to learn, because there are easier ways to get the printer to work.
8. What's coming over the wire will probably be proprietary and obfuscated.
9. Figuring out Canon's format with wireshark output will be very difficult, even for someone with experience at writing drivers.
It also inspired a comment from jrockway that offers additional practical, experienced advice.
----
What I can't figure out is what you're offering other than your approval and disapproval of what other people are doing. There's maybe one more comment on this entire thread, recently submitted, that offers more information than the one you're criticizing.
There's a big difference between "I want to make <thing>" and "I want to do <thing> that experienced individuals who know this rabbit hole and enjoy similar things but are scared of <thing>".
Fair enough. But individuals develop their own level of tolerance/dedication/grit through exposure. Let him Wireshark the shit of the USB connection to the 15yo printer. Lots to learn along the way.
Meta-response: if he truly is enthusiastic about it then a little bit of healthy discouragement just might do the trick of giving him the kick in the behind to get started. :-)
You mean like the OP's comment saying, "Ask yourself, are you trying to use the damn printer or you want a possibly educational rabbit hole to go down." Why are you being a contrarian when you're agreeing with them?
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).
How is pointing out 1. That the SNR of the answers here isn’t the best and there may be venues with better expertise (with a specific example) and 2. Pointing out the potential scope of work in any way actively discouraging?
"I'm interested in writing a x86_64 Linux driver for my 15 year old photo printer."
Is a very clear statement. Maybe if they had solicited, "how difficult would this be?" -- but that was not asked. Iterating how difficult the project is doesn't move the needle forward and in fact, does the opposite and is not at all helpful to the OP. Don't project your inadequacies.
Every single sentence in fuckstick's answer is helpful and responsive to someone who is interested in writing a driver for their printer. Including the discouragement, which communicates an expert opinion of the amount of work involved.
Can't believe I'm defending a fuckstick rn, but here we are.
> "I'm interested in writing a x86_64 Linux driver for my 15 year old photo printer." [...] is a very clear statement.
The problem is, everyone who knows a thing about "Printer drivers" shivers when they read that statement, in part because it mentions Linux or x86_64, which kind of implies some level of confusion. Also, it doesn't mention whether he's doing it for the sake of an old printer (which then makes the question the wrong thing to ask -- rather you should ask "I want to make my printer work with x86_64 Linux" -- which likely has a much simpler answer) or the sake of how to learn to write Linux printer drivers (which makes the question bizarre -- there are no Linux printer drivers per se).
> Iterating how difficult the project is doesn't move the needle forward and in fact, does the opposite and is not at all helpful to the OP. Don't project your inadequacies
This is really the wrong take here. If someone asks "I want to learn to pave roads for 4-wheel bikes" you don't answer with "OK, tarmac is made with crushed stone, tar, ...". You answer with "WTF are you doing this for?". Because it's highly likely that the questioner is having some type of confusion, rather than explicitly wanting to make such a strange request.
As Eric S. Raymond put long ago:
> Often, people who need technical help have a high-level goal in mind and get stuck on what they think is one particular path towards the goal. They come for help with the step, but don't realize that the path is wrong. It can take substantial effort to get past this.
By not addressing the user's exact question, and considering the user's final goal, you may be moving the needle much forward than if you just blindly answer it like some people have done here.
Sometimes "hacking" takes the form of finding the simplest working solution to a given problem. Reframing your assumptions or approach is IMO very valuable to at least consider, even if you ultimately stick with your initial plan.
> 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...
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.
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.