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 ²⁴⁸⁰⁄₂₅₈₀, 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).