CLI softwareFirst, can we can scan using command-line-interface software? Scanimage, pauses, but eventually goes to completion, describing the Epson model as "unknown".
$ scanimage -L...but now plug in the V30, and there's a one minute delay. After the one minute delay
device `epkowa:interpreter:001:004' is a Epson Perfection V370 Photo flatbed scanner
$ scanimage -LThe USB device name has "interpreter" in the working V370 model, but remains "usb" in the non-working model. If you want to spend some time reading "rule-out" paragraphs below, you'll see this is really the only consequential difference between the two scanners -- both scanners are properly detected and written into data files by the kernel, ruling out all hardware, firmware, or kernel problems. All that remains is driver software. The V370 has a driver that identifies it to scanning software through an "interpreter" and the V30 does not.
device `epkowa:usb:001:004' is a Epson (unknown model) flatbed scanner
finding a V30 libBy stracing $ scanimage -T to a text file for the V370, and then searching inside the text file, I noted (~line 1195)
open("/usr/lib/iscan/libiscan-plugin-perfection-v370.la", O_RDONLY) = -1 ENOENT (No such file or directory)There's a package for this on the AUR and a conversation about it on the forums. Essentially, the guy takes a DEB file from the Epson site and made it into a package for pacman/yaourt. DEB's can be installed on Arch. However, I lucked into it in yaourt.
open("/usr/lib/iscan/libiscan-plugin-perfection-v370.so", O_RDONLY|O_CLOEXEC) = 9
$ yaourt Ss v30If it doesn't take immediately, a person might also have to run
aur/iscan-plugin-gt-f720 0.1.1-1 (8) (0.01)
EPSON Image Scan! plugin for Epson Perfection V30 scanner
$ yaourt -S iscan-plugin-gt-f720
$ iscan-registry -a 0x04b8 0x0131 libesci-interpreter-gt-f720.soThe directory with the libs should include softlinks to the main lib, libesci-interpreter-gt-f720.so, eg
$ ls /usr/lib/iscan/Note: uncomment the word "usb" inside /etc/sane.d/epowka.conf, but without adding any make or model information, or it will generate two instances of the scanner. Comment-out "epowka" in /etc/sane.d/dll.conf, or conflicts will occur. See bottom of this page for further configuration file info.
Once complete, the V30 should appear as
$ scanimage -L...and scan with xsane.
device `epkowa:interpreter:001:004' is a Epson Perfection V30 flatbed scanner
Other troubleshootingThe yaourt solution was fine, however there were a lot of steps before I realized what needed to be installed for this scanner. I'd say a couple of workday's worth of effort. I learned a lot, of course, which is the standard situation in Linux. Still, I'd take half of that time back and not learn quite as much.
sane-find-scannerRunning sane-find-scanner (lsusb -vv also would have been fine) against both models, both scanners properly return hexadecimal model/product codes.
(vendor=0x04b8 [EPSON], product=0x014a [EPSON Perfection V37/V370])... and for the V30, sane-find-scanner returns...
(vendor=0x04b8 [EPSON], product=0x0131 [EPSON Scanner])Since we have the hexidecimal model code on both scanners (0131 for the V30 and 014a for the V370), firmware, hardware detection, and/or physical USB connection problems are ruled-out. The only potential oddity here is the name "Scanner" appears unspecific to any model. At this point though, we know that must be a downstream software deficit, since the firmware and hardware appear solid. There are three remaining categories of variables for this V30 problem. 1) Kernel software, application software, configuration files.
Other rule-outs: Kernel sideThe kernel creates and destroys files inside the directory /run/udev/data/ whenever a USB device is connected or disconnected to a UNIX system. User-level applications, such as xsane, then read these files for operating parameters. So we'd like to check the /run/udev/data/ files for the V30. If they're good, we know xsane is malfunctioning. If they're bad, we know the kernel is malfunctioning (or not receiving enough V30 info).
Other rule-outs: /run/udev/dataHow do we find the names of the files created when the V370 or the V30 are connected by USB? Sane-find-scanner is helpful, but we'll need to strace it to gather enough information. We'll send the two results to text files we can parse. First, the operating scanner, V370. Connect it to the USB port and, $ strace sane-find-scanner 2>&1 |tee V370file.txt . At line 700 (YMMV) of V370file.txt, we find a call to the data file c189:5:
$ grep -rn "/run/udev/data"Next, the non-scanning V30. Connect it via USB and, $ strace sane-find-scanner 2>&1 |tee V30file.txt . At line 700 (again, YMMV) of V370file.txt, we find a call to the data file c189:4:
open("/run/udev/data/c189:5", O_RDONLY|O_CLOEXEC) = 8
$ grep -rn "/run/udev/data"Now we have the names of the two data files the kernel creates, 189:5 for the V370, and 189:4 for the V30. Here's the content for the two files. The (functioning) V370
open("/run/udev/data/c189:4", O_RDONLY|O_CLOEXEC) = 8
$ cat /run/udev/data/c189:5...and, when the V30 is attached
E:ID_VENDOR_FROM_DATABASE=Seiko Epson Corp.
$ cat /run/udev/data/c189:4Since both the V370 and the V30 files are properly created inside /run/udev/data/, the kernel is now ruled-out as a problem. Secondly, these presence of these data files also probably excludes the rules the kernel uses to write data files for /run/udev/data/. These rules for helping the kernel translate a physical USB connection into a data file are in /lib/udev/rules.d/. In the case of the scanner rules, the rules file is /lib/udev/rules.d/49-sane.rules. So far, everything has checked-out normally, and now we have ruled out the kernel's USB firmware detection and data propagation processes. Good, this leaves software.
E:ID_VENDOR_FROM_DATABASE=Seiko Epson Corp.
E:ID_MODEL_FROM_DATABASE=GT-F720 [GT-S620/Perfection V30/V300 Photo]
Pausing and "Scanner"Our current working odditities are the pause with the V30 and, arguably, the name "Scanner".
# echo -1 >/sys/module/usbcore/parameters/autosuspendStill, EAGAINs were not stopped.
We know they have to do with software but, perhaps they are related, or perhaps not. we'll have to attack them separately. Now we're back to command line, like were at the top. Let's go deeper with scanimage
$ scanimage -A -d 'epkowa:usb:001:004'Both of these time-out, returning nothing.
$ scanimage -T -d 'epkowa:usb:001:005'
v370Partial information from lsusb -vv:
idVendor 0x04b8 Seiko Epson Corp.Below is the text for the /run/udev/data/c189:5 file dynamically generated when one attaches the V370. We'll need to create a rule with similar values for the V30
iManufacturer 1 EPSON
iProduct 2 EPSON Perfection V37/V370
v30Partial information from lsusb -vv
idVendor 0x04b8 Seiko Epson Corp.
idProduct 0x0131 GT-F720 [GT-S620/Perfection V30/V300 Photo]
iManufacturer 1 EPSON
iProduct 2 EPSON Scanner
Other rule-outs: configuration files
- /etc/sane.d/epson.conf - possibly could add the make and model to identify the V30, however if a yaourt or pacman solution is available, remove it.
- /etc/sane.d/saned.conf - Should not be a problem, since V370 is operating
- /etc/sane.d/dll.conf - No problems since V370 is working
- /etc/sane.d/epkowa.conf - No problems since V370 operates
- /usr/share/iscan-data/usb - Neither the 014a or the 0131 models are in this file. This file is opened during scanimage tests however.