Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How do I write a Linux driver for my 15 year old photo printer?
254 points by pushedx on Sept 14, 2022 | hide | past | favorite | 104 comments
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?




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?


Ben Eater has some videos showing the USB protocol on an oscilloscope.

https://www.youtube.com/watch?v=wdgULBpRoXk

https://www.youtube.com/watch?v=N0O5Uwc3C0o

And some videos on using chips and breadboards to meet protocols- https://www.youtube.com/watch?v=l7rce6IQDWs

And a digital protocol too- https://www.youtube.com/watch?v=MCi7dCBhVpQ


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/


https://www.packtpub.com/product/linux-kernel-development-co...

...is a pretty readable book.


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.


While normally I would agree with your comment, printers are an especially complicated class of device.

Also, the suggestion to check the arch linux forums was spot on.

I think OPs answer was very helpful and polite.


> 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]

[1] https://www.youtube.com/watch?v=w82CqjaDKmA&t=0m2s


> especially complicated class of device.

is it as complicated as calculus? or running your own e-mail server? you're perpetuating the same sentiment. Let the OP figure it out on their own.


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)


>is it as complicated as calculus? or running your own e-mail server?

In my humble opinion, way more complicated.


> is it as complicated as calculus?

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.

> Let the OP figure it out on their own.

the OP is literally soliciting opinions and help


And also go to the arch linux forums. I think everyone has been helpful and polite.


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.


I would put good odds against another similar model from the same manufacturer using 90% of the same drivers.


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).


I love how "Hacker"News threads has evolved to the point of actively discouraging people from hacking.


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?


Because it doesn't address the OPs question.

"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.


> Maybe if they had solicited, “how difficult would this be?” — but that was not asked.

Yes it was. OP asked for a “low hassle” solution, explicitly soliciting low difficulty level.


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.


Well, HN has always been more businessy I think. So a different kind of hacking.


> 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...


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.


There is hacking, then there is building skynet... cmon man dont start the singularity from a printer.


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.


> Modern printers usually work one of two ways

Are 15 year old photo printers modern?


Yes, since the tech hasn't changed much


The IPP protocol, how most printers work today over a network, first became popular about 20 years ago, and hasn't really changed much since.

Windows 2000 had full support builtin, and CUPS has had it for about the same timeframe, making it really damn easy to print anything, from any device built since, and its all in userspace.


> making it really damn easy to print anything, from any device built since

I guess at some point they had to ruin it by making all consumer printers use buggy wifi stacks.


15 years ago is only 2007.


Yeah. I think I was someone else back then. And I think quite some people and events did not yet exist back then. But printers might not have fundamentally changed in that time, the way mobile phones have for example ..


I don't recall printers changing all that much since the early 2000s at all. I mean they added USB, WiFi, Bluetooth and other such things but the protocols to talk to them largely remain the same. There's only so many ways to tell the machine to 'replicate this but on paper'.


I love the sentiment. 15 years young!


You might the PPD in a Windows installer.


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)


> Arch uses PKGBUILDs, which are roughly bash shell scripts

They are Bash scripts.


They are interpreted by makepkg, which although also written in bash, is huge.


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


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).


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


In the Canon drivers the IP1800 is included as the same package as IP3300 which is already supported in Gutenprint, so maybe that's the closest one to copy from.

https://github.com/endlessm/cnijfilter-common/blob/0c5cfbf85...


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.


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.


We can blame RMS for inspiring business to react to him with Open Source, but he started Free Software.


I'd just like to interject for a moment. What you're referring to as Free Software is actually GNU/Free Software. GNU/Free Software is not an ecosystem unto itself, but rather one component of a fully functioning GNU ecosystem.


Is this some kind of annoying autoreply for everyone who mentions RMS? Sorry for saying the guy who started the Free Software Foundation started Free Software, and not Open Source. Open Source, which is different from and often hostile to Free Software, which is also often hostile to it.


It's a meme. https://wiki.installgentoo.com/index.php/Interjection

Speaking of RMS writings and your comment, he also wrote on free software v. open source. https://www.gnu.org/philosophy/open-source-misses-the-point....

Wouldn't go that far to call them hostile.


> The two now describe almost the same category of software, but they stand for views based on fundamentally different values. For the free software movement, free software is an ethical imperative, essential respect for the users' freedom. By contrast, the philosophy of open source considers issues in terms of how to make software “better”—in a practical sense only. It says that nonfree software is an inferior solution to the practical problem at hand.

> For the free software movement, however, nonfree software is a social problem, and the solution is to stop using it and move to free software.

edit: of course it's a bit Fine Gael/Fianna Fáil, but it's hard to throw a rock without hitting an OSS advocate who thinks that Free Software is communist fascism.


Looks like RMS addressed this 4chan shitpost in the GNU website.

https://www.gnu.org/gnu/incorrect-quotation.html

Actually pretty funny! I can't believe he wrote an article about it.


> The version with Linux, we call “GNU/Linux.” It is OK to call it “GNU” when you want to be really short, but it is better to call it “GNU/Linux” so as to give Torvalds some credit.


It's so funny how he didn't actually disagree with the content of the message. Just pointed out mistakes and then went even further than the original shitpost ever did with the "it's just GNU but we should give that Torvalds some credit" thing.


> Is this some kind of annoying autoreply for everyone who mentions RMS?

Yes. I remember there was a 4chan Stallman interjector written in Perl. The script would reply to anyone talking about Linux with that text. I can't seem to find that code anymore but I found newer incarnations of the concept such as this Telegram interjector.

https://github.com/perronet/interjection-bot/blob/master/sta...


Computer history’s biggest yak shave.


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.


Unfortunately, it’s completely irrelevant to the question asked as printers are typically not driven by kernel mode device drivers.


The book covers the user space as well iirc.

And who says you can't write a kernel driver for a printer? It's certainly overkill but if you're into low level programming it's a very fascinating way to dive deeper into it, as I assumed is the case going by the last sentence of the OP.


> The book covers the user space as well iirc.

No it does not. It’s easy enough to scan the USB chapter and see that it is entirely targeting the kernel interface.

> And who says you can't write a kernel driver for a printer

Well there already is one - usblp. If you’re trying to grok the esoterica of Linux USB kernel mode interfaces - a printer class driver is not the worst exercise - but this is to me very far removed from the task at hand - driving the hardware.


Hmm you're right, now I'm sure I have to be misremembering the book I intended to link, there certainly was a chapter on user space drivers which was of course more digestible compared to LDD.

> a printer class driver is not the worst exercise

Maybe that's why it's a good introductory to kernel drivers programming? Some friends back in school were tasked the exact same thing (implement usblp 'from scratch').


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).


> What's the toolchain for sniffing USB data

You can use Wireshark for that part.

https://wiki.wireshark.org/CaptureSetup/USB


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


I bought a VueScan[1] license because of this. Awesome piece of software. There's a 5-month-old thread on it here: https://news.ycombinator.com/item?id=30760850

[1] https://www.hamrick.com/


Yep, my old Brother Printer/Scanner is no longer supported on modern versions of MacOS, but VueScan works great with it.


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.


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.


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?


Printer drivers are user space.


It looks like the 32-bit driver is closed source. The download doesn't contain any source code, despite the text on this page.

https://www.canon-europe.com/support/consumer_products/produ...


The source is available in several GitHub repos including at least one which claims to have updated the code to compile on modern systems.


That's exactly it

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


You're all jerking up the wrong tree.

The actual source is available, http://ppa.launchpad.net/thierry-f/fork-michael-gruz/ubuntu/... http://ppa.launchpad.net/thierry-f/fork-michael-gruz/ubuntu/...

etc..

The packages are compiled for x86-64.

What am i missing, no reversing required ?


These folks seem to have a 64-bit linux driver for it, for $49 eur: https://www.turboprint.info/


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.


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


https://github.com/endlessm/cnijfilter-common

You only need cnijfilter-4.10, pstocanonij and 312/libs_bin32, which are the 32-bit proprietary libraries used to communicate with your printer. Those are the ones you would want to replace.


Canon devices usually support PCL and Postscript.

The proprietary drivers are just faster/fancier.


Even the low end devices? Doesn’t postscript cost an arm and a leg to license?


I doubt it. The printer vendors paid the license fees decades ago and the patents have since expired. While researching this comment I read an article from 1997 about how Adobe changed the spec to be able to extract more revenue. Whatever patent they used as a stick has since expired.

I can't really find a definitive answer, of course, but all of the basics are from the early 90s, with some obvious followup "oh shit we need money" patents from 2000. (Obviously, 2000s era technology seems obvious today. I don't know if it was obvious in 2000. Things like "4 digit dates" were a new idea back then ;)


Nope. Source: have an old low end Canon printer/scanner combo. Pixma M270, works great but no postscript. Gutenprint drivers are available


It is so sad that printers don't do postscript anymore. Back in 1984, when 300dpi on an 8.5x11 sheet needed a whole 1 MB of memory to rasterize the entire page, that made the printers more expensive. But that excuse died a long time ago.


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.


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.


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.


Lots of great advice here along the lines of "is it really worth your time and energy", but if you really want to tackle it don't focus on the hardware, focus on the existing (proprietary) software, and wrap it with your own libraries to observe and record inputs and outputs.

  lp myfile -> input-wrapper -> proprietary-library -> system-library -> printer
                          |                             |
                          ---------floss-library---------
As the existing driver is 32-bit there are two options for debugging on a x86_64 platform:

1. A 32-bit virtual-machine install with the printer connected via USB pass-through so the existing driver correctly operates the printer

2. As someone else said, use qemu-system-i386 with a 32-bit chroot minimal install

Look at the source-code of the binary package containing the driver. Identify the proprietary binary blobs (most likely shared libraries) that are included.

Use tools like objdump to identify the names of external functions they import from system libraries (which they'll call), and the functions they export for other tools to call into.

Create basic wrapper libraries with the same names as the system libraries that export the same function names and signatures as the system library.

Have those functions in your wrapper libraries call the same functions in the system libraries and pass through the arguments untouched BUT also have your wrapper functions log/dump/record the function and arguments being passed.

In the same way create wrapper libraries that have the same name as the proprietary blob libraries and export the same functions. Have these functions call into the proprietary libraries and pass arguments untouched, and log/dump/record in the same way.

Use LD_LIBRARY_PATH to have your wrapper libraries loaded and used by the tool used to print - I'd recommend using something basic like "lp".

Do basic text printing to begin with and observe what the proprietary libraries output to the printer in response.

You'll likely see control codes to configure the printer and then possibly the actual ASCII codes of the text unless the driver converts everything to bitmaps before sending. Even then, by printing one character at a time it is usually possibly to determine the data format of bitmaps and the positioning data.

Compare with existing open-source drivers for similar devices from the same manufacturer since there is likely to be a lot of overlap and shared technology/code.

Once you think you've got a handle on it have your wrapper library that pretends to be the proprietary library bypass the proprietary library and directly format and send the data to the system libraries.

As you figure out more of the data format put that into your replacement FLOSS library until the proprietary is no longer required. At that point you can build the FLOSS library for 64-bit and upstream it for everyone to enjoy.

Or just buy a replacement printer that is well supported already!


First of all, you would need a buffer :) Just joking, I would try to check out the source code and build it under 64bit arch you have. There might be some issues on the way and start to fix them could be the first step.


I'd recommend doing some reconnaissance by looking at the 32 bit driver. What does the package contain? Prod at any binaries with binwalk, strings and maybe even Ghidra if you can to try to gather information.

If you don't understand the higher level bits of what's going on in the driver, it leaves room for a gap in understanding what exactly you might need to write to replace the 32 bit parts of the driver. If the driver works with cups, it'd be good to try to understand how exactly that works. (I'm being somewhat vague here since I don't personally know.)


Training on the kernel is probably necessary, and the Linux foundation course is expensive... but LFD430 is what you are seeking.

Primarily, there were many trends in the kernel module structures, and a lot of deprecated apis. If you just read the code, you are guaranteed have issues with the legacy code peppered in the module source.

Essentially, if you just need a USB workaround, than a user space program with libusb will greatly simplify your life. =)


Might be easier to check out the source to the 32bit driver if it works. The USB and printing protocols should already be implemented and possibly documented in the source. Then you could poke around with the 64bit drivers for similar model printers, that same protocol is probably used in other printers. Could be able to just lift the relevant code from an existing 64bit driver.


Why don't you try one of the CUPS, GutenPrint, etc. user mailing lists?

This is not the most appropriate venue for asking this type of questions.


Look at Gutenprint code for ideas. They had an open source driver for my photo printer. They might even support your printer, if getting it to work is the only objective.


The hassle is not worth it. Just buy a new, modern AirPrint compatible printer.


You can install Windows XP with printing server in virtual machine


Do you have technical documentation regarding this device?


Hackernews is primarily software. Hackaday could help




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: