This is a flatbed scanner that uses the plustek driver. usb id is 0x04a9 0x2220. Sane-find-scanner finds it at 004:004 but scanimage -L doesn't. I have tried various recommended options in /etc/sane.d/plustek.conf as suggested in this driver's man page (/dev/usbscanner, libusb 004:004, auto) without success. After googling, I also tried creating a /dev/lide25 link to /dev/usb/004/004 and putting this into plustek.conf, and also creating a sane directory under /run/lock. No luck.

The man page seems to be out of date as it expects to find data in /proc/bus/usb which doesn't exist on modern systems. I wonder if that is the problem.

I have also run it with a high value for SANE_DEBUG_PLUSTEK. Log is attached. One line that puzzles me very much is:
[plustek] ignoring >usb 0x04a9 0x2220<
Is that why it isn't working? But why does it do that?

Attached Files

plustek_scan.txt (11.5 KB, 25 views)

Guessing CanoScan LiDE25? I found it here, which I am sure you already know about: http://www.sane-project.org/sane-mfgs.html#Z-CANON

I had some issues with my lide 220 and they ended up being udev rules - permissions to the usb devices. can you run scanimage -L as root and get results?

Correct!
No, it doesn't work as root either. In any case, I'm pretty sure it's not a permissions problem. If it were, sane-find-scanner wouldn't find the scanner without root privileges, and it does. Also, if you look at the top part of the log, you can see that the scanner is detected at the correct usb bus/port. But then, for some reason, the driver ignores it.

Solved! While writing the above, I suddenly thought, "Maybe the usb port is being ignored because I added a second line to the driver configuration file." So I removed it and just left the usb ident line. And now it works.

The built-in comments in the file are very misleading.
Notice in particular the requirement for "at least two lines". If you do that, the second line actually wipes out the first, causing it to be ignored!

Glad you fixed it!

That didn't fix all of it! After writing the above, I tried an actual scan using xscanimage. It started, then crashed with "Error during device I/O". After that scanimage -L stopped working too.

This morning I tried with Debian using Xsane. Same thing happened. Well, to me that screams "Hardware problem!" I didn't know of course if it was the usb port or the cable that was playing up, so I tried a different port first. Now it works, in Debian anyway. I shall try it again in LFS later. I need to know how much of yesterday's carry on was just due to the port misbehaving rather than a real configuration error. The fact that it suddenly started working after a config file edit could be completely spurious.

Funnily enough, the Debian version of plustek.conf just has
No usb device codes at all.

It doesn't work in LFS unless I use sudo. So there's a permissions issue too, at least with this new port. Maybe with the old one too. What threw me is that the "search" programs, sane-find-scanner and scanimage -L, work in my name, but the actual scanning with xscanimage and scanimage>outfile doesn't. Looks like I need to check my udev files.

Well, at least you are making progress, sort of! I have zero familiarity with LFS so unfortunately am not able to provide any advice there. Based on your sig, I'd say you are quite adept at managing a Linux install

What seems to be happening is that the usb device keeps disconnecting and then reconnecting with a higher number. I think that is what is throwing scanimage/xscanimage. These programs need a default device spec stored in SANE_DEFAULT_SCANNER, but if it keeps changing, they can't keep up. For example, here is the latest output from scanimage -L
Bad cable?

PS: xsane actively scans for devices when it starts up rather than depending on a default scanner. Maybe that's why it works better. But it has a hellishly complex interface and I really don't like it.

Odd - could be the cable, at least that's an easy, cheap test. I agree, xsane isn't the greatest interface. Do the udev rules set the device id? I can't remember - it's been a while since I had to change configuration to get my scanner to work.

No, they just assign the new raw usb device to the scanner group. Normally (i.e. if you don't have any disconnects) the device's bus name is set at boot, depending only on what port you plugged it into, and it doesn't change. So if your scanner is always plugged into the same port, it has a constant id that you can store as the default scanner.

Yes, it was the cable. I'm using a different one now and there are no more disconnect/reconnect episodes. Result: my scanner now has a fixed usb address and scanimage/xscanimage works normally.

All the same, there should be a software solution for this. It is easy enough to get udev to run a script when a particular event (such as a usb device re-registering) takes place. But how could such a script alter one of a user's environmental variables? I use startx on LFS, so environmental variables are set initially by my bash_profile script and then carried over into my GUI. The problem is that, as far as I can determine, there is no retrospective way to alter any of them. The only thing I can think of right now is a wrapper for xscanimage that would read the current scanner address from a system file (maintained by udevd) and reset SANE_DEFAULT_SCANNER if it has changed.

Anyone got a better idea?