I'm not very experienced with graphic or printer formats. My first (and only try yet) was to print a Tux.png with 265 x 314 pixel via the Chromium browser and see what Wireshark shows as USB transfer.

I turns out that the image became a 1.540.598 byte bulk transfer (noticed because it uses a designated USB endpoint). For this I only measured the payload which divides into 188 packets of 8192 byte and one left packet with 4982 byte.

Than I tried to look into the first 81920 bytes by concatenating the payloads and read the content as 32 bit integers to see if it contains some repeating patterns which maybe looked like some continuous white or black pixels - but this didn't work.

So did anybody already started an attempt to understand the data that is sent to the printer?

It would be good to have an open source variant of the driver, because the current driver is an Intel binary and won't work for example on a Raspberry PI, which could be a cheap and current-saving print server.

Update 2014-03-10: Forgot to mention that I already found the open source drivers of Brother - but they don't contain the driver for the printer, they only provide the source for the CUPS wrapper. And just to mention it (should make no difference) I own an Brother DCP 135c.

3 Answers 3


I created a free driver for my Brother printer, available at github.com/pdewacht/brlaser. It's known to work with the Brother DCP-7030 and DCP-7065DN. If anybody tries it, I'd like to hear your feedback, it'd be useful to know which printers work with this driver and which printers don't.

  • Thank you, looks very promising. Does the brdecode.cc file decode the raw printer data stream?
    – Sven
    Commented Jul 18, 2014 at 10:21
  • 1
    Yes, brdecode is a stand-alone tool that decodes and dumps the bitmaps in the data stream. It skips over the PCL framing, but that's uninteresting anyway (identical for every page and mostly standard).
    – pdw
    Commented Jul 18, 2014 at 12:27

The way CUPS works under the hood is it ends up executing a program (the binary driver) that operates on stdin. This binary must conform to the CUPS backed interface described quite comprehensively: http://www.cups.org/documentation.php/api-filter.html

Everything else provided by the driver is just scripts and meta-data (well, who knows, but the backend program is the important one.)

For example, I happen to have a Brother MFC J415W; the Brother Linux driver installs a bunch of stuff but eventually it ends up running a binary called /opt/brother/Printers/mfcj415w/lpd/brmfcj415wfilter.

So one thing you might be able to do to make your life easier, instead of printing from a web browser, is work out how to run your backend binary directly. That should be doable by looking in the scripts to see how it gets called with what arguments and environment variables.

That way you might be able to have tighter control over which exact data gets converted for printing. You could also make a custom postscript file to push into that binary, perhaps various test patterns, like all black, all white, squares, etc., so that you may end up seeing patterns in the USB stream easier.

FWIW I ran strings on my driver and the following was in it: Compressed by Brother Ind.,Ltd. - so I suspect you are seeing a compressed data stream of some kind. It might be interesting to run something like binwalk over your stream to see whether it is able detect the compression mechanism used...


You seem to be looking for the drivers' source code: http://welcome.solutions.brother.com/bsc/public_s/id/linux/en/download_src.html

  • 3
    Sorry, I forgot to mention that I already found them, but Brother only delivers the CUPS wrapper as open source, but not the driver itself.
    – Sven
    Commented Mar 10, 2014 at 9:20
  • This link is dead. :( Commented Jun 2, 2019 at 21:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.