Packaging EPSON’s scanners’ drivers

You might remember that a couple of years ago, I bought an EPSON scanner – a GT-S50, no longer sold, replaced by the GT-S55 – to scan invoices and other kind of documents that I had laying around. The investment paid off, in my eyes, because now I have all my documents digitized, always available, and I was able to fill quite a few bags of shredded paper. The amount of work involved in digitizing that many documents without a professional scanner would have costed me in time much more than the device costed me in money.

But as I noted in the blog post above, to get the scanner to work on Gentoo Linux, I had to create ebuilds for a new package with the proprietary plugin that can handle the scanner — it’s not a sane plugin per-se, it’s rather a plugin for the EPSON-provided epkowa backend, which is otherwise opensource. I actually ended up adding two packages to the tree to be able to do that.

Nowadays, the media-gfx category hosts a number of plugins for epkowa, under iscan-plugin and esci-interpreter prefixes — the latter is the case for the GT-S50; as far as I can tell, the main difference between the two is that the latter ships with no firmware, but just a protocol interpreter, as the name suggests. Together with this, I maintain another ebuild for the plugin (32-bit only) and firmware (32- and 64-bit) for my older Perfection 2580 scanner, plus two more packages that I proxy for users who can actually test on good hardware. Today I even added another package for a scanner I don’t own, but I plan to buy when I settle down in my new residency (the 2580 stays here with my mother), the Perfection V370 which is the first one in our tree that actually uses “perfection” in the RPM name.

The ebuilds are almost identical to one another, but there are quite a few tricky bits around them. First of all, we don’t install in exactly the same locations as the RPMs — the reason for this is that they use /usr as base path for everything, but in our case, since these are provided by an external source, and are pre-built, they are installed in /opt instead, with the exception of the firmware, that stays in /usr/share simply because that’s where some of the software looks for it (namely, snapscan backend for SANE).

Some of the plugins are valid for multiple USB IDs, as is the case for the GT-S50/55/80/85 interpreter, while others are only valid for a particular ID – which may refer to multiple models anyway, as sometimes it refers to the main controller on the device, which may be shared — in the case of the 2580 noted above, it shares the same flatbed with the 2480; the difference between the two models is all in the lid, in both it hosts the lamp for scanning film, but in the 2580 it also includes the motor to load the film semi-automatically.

You can easily see which IDs the plugin applies to by using strings on the rpm and look for iscan-registry — but at this point question should be: where do you get the RPM? Well, unfortunately AVASYS no longer provides the download at a known location; EPSON themselves are distributing it, through Akamai — which means that we can’t point to the upstream servers anymore, and euscan won’t be able to find a new version being released. To solve this situation, the solution we opted for is to mirror the rpm files on my webspace on dev.gentoo.org including the needed documentation. It’s not very flexible, of course, but at least it works and it does not require us to fetch-restrict anything.

It’s hard for me to tell how many more plugins for iscan are out there, but if your scanner is among them, feel free to send an ebuild for it on our Bugzilla and CC me — you can base yourself off media-gfx/iscan-plugin-perfection-v370 which is the latest I committed.

Gentoo and EPSON scanners

“Harry,” Susan said. “Have you ever heard of the paperless office?”

“Yeah,” I said. “It’s like Bigfoot. Someone says he knows someone who saw him, but you don’t ever actually see him yourself.”

Jim Butcher — Changes

Because of the way Italian bureaucracy is designed, most of the business communications I deal with are still in paper form. And since my business lately has been covering a number of different customers, with different degrees of formality, I’ve been pretty much swamped by paper. I have been looking for ways to reduce the amount of paper I have around, or at least the amount of paper I have to look at often enough, and the solution was that to get a scanner with auto-document feeder (ADF) and keep all the new paper document scanned before either shredding or archiving them.

I settled first for an HP OfficeJet multi-function printer (which jammed so many times it wasn’t funny, but at least was cheap) and then for a LaserJet one that I was given by a family friend who couldn’t use it via USB any longer. Unfortunately it was a M1522nf, which turns out has a defective formatter card which requires either baking or replacement. HP wouldn’t replace it without paying a couple hundreds of euro, which wouldn’t be worth it at all.

I went to look for a solution, with the understanding that my current laser printer (a Kyocera-Mita FS-1020D) is quite a charm to use, especially now that it is no longer connected to an Apple Airport Extreme, but rather to my Gentoo-based router whose cups instance is directly referenced by both Yamato and Raven so that I don’t have to run it on them any longer. I went to look at more professional, office-oriented scanners, since the only one I could find in “entry level” by HP listed a duty cycle of 100 scans/day (which I’m sure I would bust easily; a bank-related contract is usually longer).

The requirements, beside being able to scan a decent amount of sheets (more than 20) were generally the usual you’d expect for a person like me: it has to work with Linux, possibly 64-bit, with preferably no prebuilt, proprietary software. To be honest, this doesn’t seem to be feasible at all. And before somebody asks, no HP is not much better. Sure HPLIP is open source and Free, but to use the scanner in the aforementioned M1522nf, you have to install their proprietary plugin bits. Canon scanners, which seems to be the cheapest with Linux support for ADF, are supported by their driver, but it’s totally proprietary and more importantly it only works on 32-bit systems.

EPSON, instead, seems to have a more interesting approach. The Avasys-developed epkowa backend for sane is actually quite nice: it encapsulates a decently-sized open-source backend with a number of proprietary plugins (and in some cases firmware files). I already had a bit of experience with that backend before, since my flatbed scanner is a Perfection 24802580, but with that I couldn’t make use of it in a long time simply because the non-basic functionality (film scanning) is supported by a 32-bit only plugin.

After snooping around and poking my hardware supplier about it, I decided to get a GT-S50 (sheet-fed) document scanner, which is shaped more like an inkjet printer or a fax machine than a scanner. This time as well a plugin is needed, so based on the GT-F720 ebuild that was already in tree I wrote one for the required plugin (and also one for the GT-F500 plugin that is used by the Perfection above — but the only task I can use it for is to install the firmware file used by snapscan, so if you want to try it on 32-bit please let me know if it works at all!). You can now find iscan-plugin-gt-s80 (it includes support for both S50 and S80) and iscan-plugin-gt-f500 in tree already.

I got the scanner on Friday evening and set it up; the driver worked at the first try, and the iscan tool provided by Avasys/Epson works just right. On the other hand, my customized script over scanimage (as provided by sane-backends) was not working properly when scanning duplex (i.e. both sides of the sheet at once). In such a configuration, a single pass of the sheet in the ADF causes two pages to be read; the driver (or the firmware, not sure) caches the back side as the second page, and the next time sane is asked for a page, it returns the one already scanned. When doing the second scan, it was random whether it worked or not: a race condition.

I haven’t spent enough time on it yet to know where the problem lies exactly: it might be a bug in the scanimage frontend (given that iscan works fine), or a bug in the drivers. At any rate for now I worked it around by adding a sleep(1) before calling sane_start() in the file. You can find a hacked 1.0.22 ebuild for sane-backends in my overlay if you happen to have similar problems.

At the end of the day, I’m pretty happy with the device, it scans very nicely, very fast and has a high enough duty cycle for the kind of stress I could make it go through. Once I’ll be able to resolve the above-noted issue with scanimage it’ll work much better. But there are a few issues that still need to be solved, such as:

  • iscan needs to be set to use /var/lib/iscan rather than the current /var/lib/lib/iscan, and that requires plugins to be re-registered;
  • I need to find a way to register the plugin properly when installing in a different ROOT, which right now neither of my ebuilds do;
  • the iscan-plugin-gt-f720 ebuild needs to be brought up to speed with the other two, as right now it seems sub-par (among other things it installs the plugins in /usr — which, albeit being what AVASYS does on RedHat systems, is wrong, as they should go in /opt).