[solved] Epson V30 (04b8:0131) v. V370 (04b8:0141a)

nb: 2022 - subbed "yay" for all "yaourt"

short version

Neither scanner will be detected in $ scanimage -L unless correct driver is used. Typically the V30 works well with only the driver, whereas the V370 needs the driver and may also need "epowka" adjustments described further down this page. Neither scanner requires CUPS.

V30 (04b8:0131) - $ yay -S iscan-plugin-gt-f720

V370 (04b8:014a) - $ yay -S iscan-plugin-perfection-v370

If still no proper V370 detection, check the "epowka" and "hpaio" notes further down. I've never been able to configure a box for both scanners so I could hook up either. I remove the driver for the scanner not being used.

---

prevention

• check the connection

  $ lsusb
  ID 04b8:0131 Seiko Epson Corp. GT-F720 [GT-S620/Perfection V30/V300 Photo]

• install and enable cups

  # pacman -S cups
  # systemctl list-unit-files |grep cups
  [if necesary....]
  # systemctl enable cups.service
  # systemctl restart cups.service

• can play with turning cups on and off or even uninstalling it later, but it's likely to be initially necessary for the scanner to successfully build against
• install the AUR driver

  $ yay -S iscan-plugin-gt-f720

• verify it's a detected scanner

  $ scanimage -L
  device `epkowa:interpreter:001:006' is a Epson Perfection V30 flatbed scanner

• try a test scan with, e.g. xsane

problem

Initiating the GUI xsane application with a USB-connected Epson V30 scanner results in a pause, then termination of the xsane application (without scanning). Connecting an Epson V370, the same actions result in normal xsane scanning operations. Using a known-good, functioning USB-connected Epson V370, let's run similar applications on both the V370 and the non-functioning V30, until we can find a difference, and hopefully solve the V30 non-operation.

---

CLI software

First, can we at least detect the V30 using the command-line? Two command line interface (CLI) scanner probes, scanimage and sane-find-scanner, verify slightly different features. Scanimage is the more thorough. Scanimage on the V30 pauses, but eventually goes to completion, describing the V30 as "unknown model".

$ scanimage -L
device `epkowa:usb:001:004' is a Epson (unknown model) flatbed scanner

... on the V370 there's no delay and the model name is identified.

$ scanimage -L
device `epkowa:interpreter:001:004' is a Epson Perfection V370 Photo flatbed scanner

Model name aside, the V30 and V370 are properly detected and trigger the kernel to create data files; we can rule-out hardware, firmware, or kernel problems. Since the USB device name for the V370 includes "interpreter", but the V30 device name remains "usb"; the kernel is not receiving additional information for the V30, beyond the simple usb connection. Let's locate the (operational) V370 driver on the hard drive, and see if the V30 is in the same folder and perhaps not working.
Attaching the USB V370, and stracing $ scanimage -T ($ strace scanimage -T 2>&1 |tee V370file.txt) and then searching inside the resulting text file, I noted (~line 1195)

open("/usr/lib/iscan/libiscan-plugin-perfection-v370.la", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/iscan/libiscan-plugin-perfection-v370.so", O_RDONLY|O_CLOEXEC) = 9

The V370 driver inside /usr/lib/iscan, however I could find no driver relevant to the V30 in that folder. It appears we're lacking a V30 driver. A V30 driver would give the kernel more information than "usb".

driver software

I lucked into a premade AUR version of the V30 driver -- one step with yaourt. A conversation about this driver exists on the forums. Apparently, the creator downloaded a DEB file from the Epson site and then converted the DEB into a pacman/yaourt package. It's probably also worth noting that DEB's can be directly installed on Arch with a couple of steps. In this case, I had the premade AUR version I could install more easily using yaourt.

$ yaourt Ss v30
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

After installation, the V30 should appear with its model information and "interpreter" instead of "usb"...

$ scanimage -L
device `epkowa:interpreter:001:004' is a Epson Perfection V30 flatbed scanner

...and scan images via xsane.

possible tweaks

If there are still problems, check the following.

• Uncomment "usb" inside /etc/sane.d/epowka.conf, but without adding any make or model information, just leave it as "usb". If you add make or model, scanimage may generate a second, conflicting, instance of the V30.
• Comment "epowka" in /etc/sane.d/dll.conf, or conflicts will occur.
• The scanner libs directory should include softlinks to the main lib, libesci-interpreter-gt-f720.so, eg

  $ ls /usr/lib/iscan/
  libesci-interpreter-gt-f720.so
  libesci-interpreter-gt-f720.so.0
  libesci-interpreter-gt-f720.so.0.0.0

• Run

  $ iscan-registry -a 0x04b8 0x0131 libesci-interpreter-gt-f720.so

See bottom of this page for more configuration file info.

---

Troubleshooting prior to yaourt

block hpaio

Sometimes hpaio loads when there's no HP scanner. Like many Linux apps, they either don't work at all or they can never be disabled. Hpaio won't stop the V30 or other scanners, but it's a hardcore annoyance since it's impossible to turn off via any interface, by disabling CUPS, etc. I got tired of this fast and blacklisted the sumb*tch. Find the names of the hp-related libsane files in /lib/sane.d/, because you can't find it and its dependencies the normal way...

# modinfo -F depends libsane-hp
modinfo: ERROR: Module libsane-hp not found.

... and then blacklist them via /etc/modprobe.d/blacklisted.conf (you can call the file anything).

# nano /etc/modprobe.d/blacklisted.conf
# stop hpaio annoyance when no hp scanner connected
install libsane-hpaio /bin/true
install libsane-hp /bin/true

xsane also loads hpaio

Any time xsane is initiated, xsane finds these hpaio drivers and loads them directly. Stracing xsane

open("./dll.d", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/etc/sane.d/dll.d", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 7
fstat64(7, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getdents(7, /* 4 entries */, 32768) = 76
1572:stat64("/etc/sane.d/dll.d/hpaio", {st_mode=S_IFREG|0644, st_size=6, ...}) = 0
1573:open("./dll.d/hpaio", O_RDONLY) = -1 ENOENT (No such file or directory)
1574:open("/etc/sane.d/dll.d/hpaio", O_RDONLY) = 8
1576:read(8, "hpaio\n", 4096) = 6
4071:open("/usr/lib/sane/libsane-hpaio.so.1", O_RDONLY) = 19
4073:open("/usr/lib/sane/libsane-hpaio.so.1", O_RDONLY|O_CLOEXEC) = 19

so you will also have to disable xsane from activating hpaio.

# nano /etc/sane.d/dll.d/hpaio
# comment the following so hpaio doesn't load.
#hpaio

Note: don't forget that, if an HP scanner is ever connected, you'll need to undo these changes to both /etc/sane.d/dll.d/hpaio and to /etc/modprobe.d/blacklisted.conf.

---

But back to yaourt. Yaourt was the end-point, yet I had proceeded through several troubleshooting steps to determine the driver issue. A couple of workday's worth of effort were spent ruling-out any physical connection, firmware, kernel, or configuration files. Some of that is noted above, the remainder is below.

lsub -vv (v370)

Partial information from lsusb -vv:

idVendor 0x04b8 Seiko Epson Corp.
idProduct 0x014a
bcdDevice 1.00
iManufacturer 1 EPSON
iProduct 2 EPSON Perfection V37/V370
iSerial 0

lsub -vv (v30)

Partial information from lsusb -vv

idVendor 0x04b8 Seiko Epson Corp.
idProduct 0x0131 GT-F720 [GT-S620/Perfection V30/V300 Photo]
bcdDevice 1.00
iManufacturer 1 EPSON
iProduct 2 EPSON Scanner
iSerial 0

sane-find-scanner

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

I also attempted to get attributes and do tests on the V30, prior to yaourt.

$ scanimage -A -d 'epkowa:usb:001:004'
$ scanimage -T -d 'epkowa:usb:001:005'

Both of these time-out, returning nothing however, 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. There are three remaining categories of variables for this V30 problem. 1) Kernel software, application software, configuration files.

Kernel side

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

/run/udev/data

How 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"
open("/run/udev/data/c189:5", O_RDONLY|O_CLOEXEC) = 8

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:

$ grep -rn "/run/udev/data"
open("/run/udev/data/c189:4", O_RDONLY|O_CLOEXEC) = 8

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

$ cat /run/udev/data/c189:5
I:97119577141
E:ID_VENDOR=EPSON
E:ID_VENDOR_ENC=EPSON
E:ID_VENDOR_ID=04b8
E:ID_MODEL=EPSON_Perfection_V37_V370
E:ID_MODEL_ENC=EPSON\x20Perfection\x20V37\x2fV370
E:ID_MODEL_ID=014a
E:ID_REVISION=0100
E:ID_SERIAL=EPSON_EPSON_Perfection_V37_V370
E:ID_BUS=usb
E:ID_USB_INTERFACES=:ffffff:
E:libsane_matched=yes
E:ID_VENDOR_FROM_DATABASE=Seiko Epson Corp.
E:ID_PATH=pci-0000:00:12.2-usb-0:2
E:ID_PATH_TAG=pci-0000_00_12_2-usb-0_2
E:ID_FOR_SEAT=usb-pci-0000_00_12_2-usb-0_2
G:uaccess
G:seat

...and, when the V30 is attached

$ cat /run/udev/data/c189:4
I:138131813751
E:ID_VENDOR=EPSON
E:ID_VENDOR_ENC=EPSON
E:ID_VENDOR_ID=04b8
E:ID_MODEL=EPSON_Scanner
E:ID_MODEL_ENC=EPSON\x20Scanner
E:ID_MODEL_ID=0131
E:ID_REVISION=0100
E:ID_SERIAL=EPSON_EPSON_Scanner
E:ID_BUS=usb
E:ID_USB_INTERFACES=:ffffff:
E:libsane_matched=yes
E:ID_VENDOR_FROM_DATABASE=Seiko Epson Corp.
E:ID_MODEL_FROM_DATABASE=GT-F720 [GT-S620/Perfection V30/V300 Photo]
E:ID_PATH=pci-0000:00:12.2-usb-0:2
E:ID_PATH_TAG=pci-0000_00_12_2-usb-0_2
E:ID_FOR_SEAT=usb-pci-0000_00_12_2-usb-0_2
G:uaccess
G:seat

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

Unsolved

Our current unsolved clues related to the non-scanning are 1) the pause and eventual time-out when V30 is queried, 2) the unnamed model "Scanner", 3) the name "usb", instead of "interpreter" inside scanimage -L results.

# echo -1 >/sys/module/usbcore/parameters/autosuspend

Still, EAGAINs and the pauses did not stop, and this led me, finally, to a driver.

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.