[SOLVED] xsane problems with F20 and Epson 3490 photo

terry-duell · 12-28-2014, 09:36 PM

Quote:

Originally Posted by Ztcoracat

I'm not sure Terry (best to wait and see what unSpawn thinks)

Configuration files assist process and devices that we want to work. (aside from drivers assisting the hardware)
I wonder if it is as simple as adding an argument to the file you already have? (Again let's see what unSpawn suggest's)
I called on him because he has more experience and I trust him.

It could also be that sane needs to be updated.
Maybe updating will help. Just run:
su -c 'yum update xsane'
and see if it helps.

I have just been through the process so reckon that would be all up to date.

Quote:

Another thing that I found out while I was looking up all the details of sane is that The binary driver needs a libsane.dll from Sane version 1.0.16 or later. A fancy name for the backend driver I think.

I have /lib64/libsane.so.1.0.24 and /lib64/sane/libsane-dll.so.1.0.24

Quote:

Is this the place where you downloaded your binary driver here?
http://rpm.pbone.net/index.php3?stat...sane&srodzaj=3

My binary driver (assuming you mean esfw52.bin, which is pointed to in /etc/sane.d/snapscan.conf) was on the Epson disk which accompanied the scanner.
I have been wondering if there was another binary that was needed which maybe disappeared when moving from Fedora 19 to Fedora 20, but have not been able to find anything that looks right. Everything I have seen thus far has been for i386. x86_64 stuff nowhere to be seen now, although I see references to x86_64 rpms from as recent as early 2014, I can't locate them...and they may be irrelevant anyway. Recall, that Xsane, via the Gimp plugin will produce a preview scan (sometimes) which may be an unlikely outcome if there was a driver missing (guessing again!).

Cheers,
Terry

Ztcoracat · 12-28-2014, 10:05 PM

Quote:

Originally Posted by terry-duell

I have just been through the process so reckon that would be all up to date.

I have /lib64/libsane.so.1.0.24 and /lib64/sane/libsane-dll.so.1.0.24

My binary driver (assuming you mean esfw52.bin, which is pointed to in /etc/sane.d/snapscan.conf) was on the Epson disk which accompanied the scanner.
I have been wondering if there was another binary that was needed which maybe disappeared when moving from Fedora 19 to Fedora 20, but have not been able to find anything that looks right. Everything I have seen thus far has been for i386. x86_64 stuff nowhere to be seen now, although I see references to x86_64 rpms from as recent as early 2014, I can't locate them...and they may be irrelevant anyway. Recall, that Xsane, via the Gimp plugin will produce a preview scan (sometimes) which may be an unlikely outcome if there was a driver missing (guessing again!).

Cheers,
Terry

When I was running FC I only trusted the .rpm packages for my distribution.
But that's just me.

I'm looking here in this thread to see if post #3 will help. It looks like a possibility.
http://www.linuxquestions.org/questi...er-4175495728/

Uncommenting that line in the /etc/sane.d/snapscan.conf (might) just be the answer.

If you don't have "/etc/sane.d/snapscan.conf" than maybe try uncommenting #usb /dev/usbscanner0 in your 'epsonconf' file.

-:- If you do uncomment those arguments and you still don't get performance from the scanner you can always undue what you did with your text editor-:-

--OFF Topic--
Not that the network/interfaces file is relavant to your sane.d file but in my case my wireless wouldn't work because Wired was uncommented and Wireless was commented out. As soon as I uncommented Wireless and rebooted my wireless worked.
I played around with arguments in config files to get things working.

terry-duell · 12-28-2014, 11:29 PM

Quote:

Originally Posted by Ztcoracat

When I was running FC I only trusted the .rpm packages for my distribution.
But that's just me.

That's where all mine come from.

Quote:

I'm looking here in this thread to see if post #3 will help. It looks like a possibility.
http://www.linuxquestions.org/questi...er-4175495728/

Uncommenting that line in the /etc/sane.d/snapscan.conf (might) just be the answer.

That's where you point to the Epson binary driver (or maybe it's firmware) "esfw52.bin", and have done that as discussed previously.

Quote:

If you don't have "/etc/sane.d/snapscan.conf" than maybe try uncommenting #usb /dev/usbscanner0 in your 'epsonconf' file.

I think I have tried that, but will have another go. I think I have tried all combinations and permutations!!
Note that there is an /etc/sane.d/epson.conf and a /etc/sane.d/epson2.conf, which are referred to in /etc/sane.d/dll.conf.
I think the original dll.conf had epson2 uncommented and epson commented out...haven't seen any advice anywhere as to when one is meant to use epson.conf and when to use epson2.conf.

Quote:

-:- If you do uncomment those arguments and you still don't get performance from the scanner you can always undue what you did with your text editor-:-

--OFF Topic--
Not that the network/interfaces file is relavant to your sane.d file but in my case my wireless wouldn't work because Wired was uncommented and Wireless was commented out. As soon as I uncommented Wireless and rebooted my wireless worked.
I played around with arguments in config files to get things working.

Yes, it's easy to recover...just need to keep good notes or copies of what you edit.

Cheers,
Terry

terry-duell · 12-28-2014, 11:58 PM

Quote:

Originally Posted by terry-duell

Note that there is an /etc/sane.d/epson.conf and a /etc/sane.d/epson2.conf, which are referred to in /etc/sane.d/dll.conf.
I think the original dll.conf had epson2 uncommented and epson commented out...haven't seen any advice anywhere as to when one is meant to use epson.conf and when to use epson2.conf.

I think I can now elaborate a bit on this.
I have a separate disk with my old Fedora 19 installation, and browsed through the /etc/sane.d/ files. I note that dll.conf had everything except snapscan commented out, which rings a very faint bell, which if correct implies that when using snapscan and the Epson binary firmware file, one doesn't need any of the epson.conf files.
So, made that change, and all's still the same...Xsane via Gimp puts up a preview scan OK but "scan" returns "device IO error".
I have also tried using a front panel USB port instead of back panel USB, also tried USB2 port...all to no avail.
Looking forward to Great insights from unSpawn :-)

Cheers,
Terry

Ztcoracat · 12-29-2014, 12:18 AM

Quote:

Looking forward to Great insights from unSpawn :-

Me too; Terry:-

-:- I have went through all that I know to try; Sorry I don't know more. I gave it my best.-

-:-

I learned this from or Guru Mr. Frankbell:
"Troubleshooting is eliminating possible sources of trouble, one at a time, with certainty."

If you keep at something long enough you will eventually find what the problem is.

unSpawn · 12-29-2014, 05:02 AM

Quote:

Originally Posted by terry-duell

Firstly, is exasperation I un-installed all xsane and sane packages then reinstalled, and reset config files. Also found another new USB cable and installed that.

Its good you tried another cable but I hope you see why removing and installing software would kind of defeat the purpose of troubleshooting...

Quote:

Originally Posted by terry-duell

The results of the tests (at 0. above) are in attached file "sane_root_tests.txt". (..) Attached is my /etc/sane.d/epson.conf as "epsonconf.txt"
I have the epson firmware file "esfw52.bin" in /usr/share/sane/snapscan/ and I have changed permissions on this file (chmod 777).

Thanks. Confirmed as USB device "vendor=0x04b8 [EPSON], product=0x0122 [EPSON Scanner]" (as /etc/sane.d/snapscan.conf would show).
Couple of approaches I can see:

0) Loathe as I am to advise so, see if turning off SELinux (set "SELINUX=disabled" in /etc/selinux/config then reboot) and scanning as root works.

1) First, to isolate things, there's a few things:
- note libraries have octal mode 0755 and not 0777. Please correct that.
- Download https://ftp.epson.com/drivers/epson13829.exe, unzip it then 'cabextract modusd.cab' and check if the "esfw52.bin" therein differs from yours.
- Your /etc/sane.d/epson.conf should read:

Code:

# epson.conf
usb 0x4b8 0x122

(no uncommented SCSI, sole "usb", no USB scanner lines either as the "scanner" module doesn't seem to like those or any other lines).
- Just to make certain make /etc/sane.d/epson2.conf have the same contents.
- Now disable all backends in /etc/sane.d/dll.conf then uncomment only the "epson" and "epson2" lines:

Code:

sed -i "s|^.|#\0|g" /etc/sane.d/dll.conf

- Check if you have a "/usr/lib/udev/rules.d/*sane*.rules" file and look for a line with the "3490" in it else add one (let's see if 'scanimage -L' then picks it up):

Code:

# EPSON Perfection 3490 PHOTO
ATTR{idVendor}=="04b8", ATTR{idProduct}=="0122", ATTRS{vendor}=="EPSON", ATTRS{model}=="Perfection3490", ENV{libsane_matched}="yes", SYMLINK+="scanner-%k"

- Now add these lines to /etc/rc.d/rc.local before the "exit 0" line:

Code:

export SANE_DEBUG_EPSON=128
export SANE_DEBUG_EPSON2=128
export SANE_DEBUG_SANEI_USB=4
export SANE_DEBUG_SNAPSCAN=2

- then check if rc.local is enabled and loaded:

Code:

systemctl status rc-local.service || { systemctl enable rc-local.service && systemctl start rc-local.service; }

then run the whole sequence from my previous post again in the hope this will emit more debug nfo.

2) The same as #1 but with the addition that you run this first on encountering an error:

Code:

rmmod scanner && modprobe scanner vendor=0x04b8 product=0x0122

3) The same as #1 but calling xsane explicitly from the command line with:

Code:

xsane epson

or

Code:

xsane epson:libusb:003:002

4) You're running SANE version 1.0.24 and SANE backends list the Epson 3490 now using the EPKOWA backend with the remark "multi photo feeder not supported, requires DFSG non-free iscan-plugin-gt-f520, also supported by the snapscan backend, overseas version of the GT-F520".
This means (re?)installing vintage 2011 iscan software from http://download.ebz.epson.net/dsc/se...search/?OSC=LX and the Fedora iscan-firmware iscan-plugin-gt-f520* .rpm. Note I have no clue if this is invasive so unless you know what you're doing I would keep it as a last resort option.

5) Due to bug 961370 and bug 1053566 check what kernel you run and if scanning works with another kernel. Note this is invasive and potentially destructive so unless you know what you're doing I would definitely keep this one as the ultimate last resort option.

...and there you have it. Let's see if we can make it spit out enough debug nfo.

terry-duell · 12-29-2014, 05:13 PM

Thanks for your very detailed response.
I have run into a problem, so best to deal with that first.

Quote:

Originally Posted by unSpawn

- Now add these lines to /etc/rc.d/rc.local before the "exit 0" line:

Code:

export SANE_DEBUG_EPSON=128
export SANE_DEBUG_EPSON2=128
export SANE_DEBUG_SANEI_USB=4
export SANE_DEBUG_SNAPSCAN=2

- then check if rc.local is enabled and loaded:

Code:

systemctl status rc-local.service || { systemctl enable rc-local.service && systemctl start rc-local.service; }

then run the whole sequence from my previous post again in the hope this will emit more debug nfo.

I don't have an /etc/rc.d/rc.local, so created one, as best I could, owned by root, executable,...as follows;

Code:

#!/bin/bash

export SANE_DEBUG_EPSON=128
export SANE_DEBUG_EPSON2=128
export SANE_DEBUG_SANEI_USB=4
export SANE_DEBUG_SNAPSCAN=2

exit 0

and got this response to checking rc.local enabled...

Code:

[terry@localhost ~]$ systemctl status rc-local.service || { systemctl enable rc-local.service && systemctl start rc-local.service; }
rc-local.service - /etc/rc.d/rc.local Compatibility
   Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static)
   Active: inactive (dead)

Failed to issue method call: Access denied

I repeated this but preceeded by "sudo", with same result.

...so, I have probably done something wrong.

Cheers,
Terry

unSpawn · 12-29-2014, 06:34 PM

Hmmm. /etc/rc.d/rc.local should be part of the "initscripts" package but OK. Apparently the error has to do with https://fedoraproject.org/wiki/Featu...dAccessControl ... Try

Code:

chcon -u system_u -r object_r -t initrc_exec_t /etc/rc.d/rc.local

then reboot and log in on the command line or open a terminal window (any user will do) and see if the environment variables are there with

Code:

env|grep SANE

Ztcoracat · 12-29-2014, 07:26 PM

Thanks for the link unSpawn.

terry-duell · 12-29-2014, 07:36 PM

Quote:

Originally Posted by unSpawn

Hmmm. /etc/rc.d/rc.local should be part of the "initscripts" package but OK. Apparently the error has to do with https://fedoraproject.org/wiki/Featu...dAccessControl ... Try

Code:

chcon -u system_u -r object_r -t initrc_exec_t /etc/rc.d/rc.local

then reboot and log in on the command line or open a terminal window (any user will do) and see if the environment variables are there with

Code:

env|grep SANE

OK, did the "chcon..." (mouse copied from your post) but got permission denied, so used sudo, then it appeared to be OK.

Reboot, in terminal.

Code:

[terry@localhost ~]$ env|grep SANE
[terry@localhost ~]$

'no response' was the stern reply!!

Looking back at your earlier detailed post, I can report that turning off SELinux had no effect.
A question re your

Quote:

no uncommented SCSI, sole "usb", no USB scanner lines either as the "scanner" module doesn't seem to like those or any other lines).
- Just to make certain make /etc/sane.d/epson2.conf have the same contents.
- Now disable all backends in /etc/sane.d/dll.conf then uncomment only the "epson" and "epson2" lines:

Are you sure that "snapscan" should be commented out in /etc/sane.d/dll.conf? I would have guessed snapscan is needed so the path to the esfw52.bin (provided in snapscan.conf) can be found.
With snapscan commented out, but other changes as detailed, attempting to open Gimp XSane dialog results in "no devices found", but if I uncomment snapscan in /etc/sane.d/dll.conf, I get the message "Fialed to open device 'snapscan:libusb:003:002' access to resource has been denied".

Cheers,
Terry

terry-duell · 12-30-2014, 07:05 PM

Catching up on few outstanding things...

Quote:

Originally Posted by unSpawn

0) Loathe as I am to advise so, see if turning off SELinux (set "SELINUX=disabled" in /etc/selinux/config then reboot) and scanning as root works.

With SELINUX disabled I have the same problem.

Quote:

1) First, to isolate things, there's a few things:
- note libraries have octal mode 0755 and not 0777. Please correct that.
- Download https://ftp.epson.com/drivers/epson13829.exe, unzip it then 'cabextract modusd.cab' and check if the "esfw52.bin" therein differs from yours.

I did an md5 checksum on the two binaries and they are the same.

I have been cautious about stating how I think it all has been set up, as it can be unwise to rely on memory being 100% correct. The repeated work on this over the last few days has made me a bit more sure about it all, and thankfully, I do have some records that help.
I have been using Redhat/Fedora since 2000, and upgrading (usually by a clean install) when each new version is released.
My old hand written notes indicate that apart from installing all the sane and xsane rpms, I had to edit /etc/sane.d/snapscan.conf to add the path to the epson binary firmware file esfw52.bin, and put esfw52.bin in /usr/share/sane/snapscan/. It is my recollection that I always used the snapscan driver and there is no reference in my notes to any epson or other third party drivers being installed.
In later years, I would run a script to capture a list of all the installed packages before a clean install, then run a script to capture a list of all the installed packages on the new system, then a script to find a list of package names that needed to be installed on the new system to bring the new system up to date.
I still have those package lists/names for Fedora 17 to 18, 18 to 19 and 19 to 20, and the only relevant packages that were installed were (from the 17 to 18 upgrade)...

sane-backends-drivers-scanners 1.0.23-4.fc17 x86_64
sane-backends-libs 1.0.23-4.fc17 x86_64
xsane-gimp 0.998-12.fc17 x86_64
xsane-common 0.998-12.fc17 x86_64
sane-backends 1.0.23-4.fc17 x86_64
xsane 0.998-12.fc17 x86_64

which confirms in my mind that I was using the snapscan driver.

So, (thinking out loud) that suggests to me that sometime in the (recent) past ( I can't really say how long ago I last used the scanner without problems...it may have been Fedora 18 or even Fedora 17) the snapscan driver has changed and no longer supports my scanner, or it may be the reported problem of the kernel not loading the scanner firmware.
I run and up-to-date Fedora 20, and the current kernel is 3.17.7.

@unSpawn; I guess we should run all the tests that you have listed, once we have the debug stuff in rc.local working OK, but does any of the above suggest any new thoughts?

Cheers,
Terry

unSpawn · 12-31-2014, 04:53 AM

Quote:

Originally Posted by terry-duell

With SELINUX disabled I have the same problem.

Good, good. That at least suggests it's not a policy problem.

Quote:

Originally Posted by terry-duell

I did an md5 checksum on the two binaries and they are the same.

Good!

Quote:

Originally Posted by terry-duell

I have been using Redhat/Fedora since 2000, and upgrading (usually by a clean install) when each new version is released. My old hand written notes indicate (..) I still have those package lists/names for Fedora 17 to 18, 18 to 19 and 19 to 20, and the only relevant packages that were installed were (from the 17 to 18 upgrade)...

sane-backends-drivers-scanners 1.0.23-4.fc17 x86_64
sane-backends-libs 1.0.23-4.fc17 x86_64
xsane-gimp 0.998-12.fc17 x86_64
xsane-common 0.998-12.fc17 x86_64
sane-backends 1.0.23-4.fc17 x86_64
xsane 0.998-12.fc17 x86_64

which confirms in my mind that I was using the snapscan driver.

You've been working methodically and documenting things thoroughly and it pays off. Excellent!

Quote:

Originally Posted by terry-duell

So, (thinking out loud) that suggests to me that sometime in the (recent) past ( I can't really say how long ago I last used the scanner without problems...it may have been Fedora 18 or even Fedora 17) the snapscan driver has changed and no longer supports my scanner, or it may be the reported problem of the kernel not loading the scanner firmware. I run and up-to-date Fedora 20, and the current kernel is 3.17.7.

@unSpawn; I guess we should run all the tests that you have listed, once we have the debug stuff in rc.local working OK, but does any of the above suggest any new thoughts?

Well, that certainly is an avenue to explore. Basically there's two things: the kernel (or rather the controller, bus and device layer interfaces it provides) and user land software. Maybe you remember that back in the day USB devices required a certain amount of kernel modules to be loaded, a few of them having "scsi" in their name. Now these USB devices weren't actual SCSI devices but (unless I'm mistaken) it was because part of the kernels SCSI abstraction layer was used. The problem with some kernel interfaces is they've been subject to quite a few cleanups and changes between 2.6 and 3.x kernels... So what are we actually looking at? Let's use one of the public kernel cross referencers (lxr.free-electrons.com). A summary of USB drivers in relation to kernel 3.2: http://lxr.free-electrons.com/source/drivers/usb/?v=3.2, a description of provided drivers in kernel 3.8: http://lxr.free-electrons.com/source...ices.txt?v=3.8, a description of how to get USB scanners to work with kernel 2.4.37: http://lxr.free-electrons.com/source...r.txt?v=2.4.37, the header file http://lxr.free-electrons.com/source...ner.h?v=2.4.37 and driver code http://lxr.free-electrons.com/source...ner.c?v=2.4.37 for USB scanners in kernel 2.4.37. I'm not saying that's all but diffing whatever changed in /source/drivers/usb/ could be a quick win. On the SANE end http://www.sane-project.org/cvs.html provides access to its GIT repositories so if you would rather like to start there in the hope it's only a user land driver problem that's an option too. OK, so I said there's two things but there aren't ;-p Since you've been using Fedora that's one thing to factor in as well in terms of specific patches and bug tracker research.

Come to think of it, another way could be for you to get on the SANE users mailing list and ask them to help you. In fact that may be the quickest way to get confirmation if this is a problem with SANE or Something Completely Different (unavoidable MPFC reference)...

terry-duell · 01-01-2015, 10:55 PM

I can now report that the problem appears to be solved.
I got a copy of the sane-backends GIT repo, and the Fedora sane-backends-1.0.24-7.fc20.src.rpm, and built new sane-backends-libs, sane-backends, sane-backends-drivers-scanners using rpmbuild, but without using any of the patches that are included in the Fedora sane-backends-1.0.24-7.fc20.src.rpm.
It built OK, and installed OK.
The scanner is now working as I remember it did (just like a bought one!).
So, not exactly sure what it fixed, but given that it "always" worked then didn't, I assume it was due to some change in Fedora 20 that the current GIT source have fixed.
It is curious that others haven't had this problem...maybe I'm the only one using Fedora 20 and an Epson 3490 with snapscan.

Thanks to all who tried to help, and hopefully this may help any others who do have the problem I reported. Note that it is not clear when current GIT source for sane-backends will reach Fedora.

Cheers,
Terry

Ztcoracat · 01-02-2015, 04:14 PM

Quote:

Originally Posted by terry-duell

I can now report that the problem appears to be solved.
I got a copy of the sane-backends GIT repo, and the Fedora sane-backends-1.0.24-7.fc20.src.rpm, and built new sane-backends-libs, sane-backends, sane-backends-drivers-scanners using rpmbuild, but without using any of the patches that are included in the Fedora sane-backends-1.0.24-7.fc20.src.rpm.
It built OK, and installed OK.
The scanner is now working as I remember it did (just like a bought one!).
So, not exactly sure what it fixed, but given that it "always" worked then didn't, I assume it was due to some change in Fedora 20 that the current GIT source have fixed.
It is curious that others haven't had this problem...maybe I'm the only one using Fedora 20 and an Epson 3490 with snapscan.

Thanks to all who tried to help, and hopefully this may help any others who do have the problem I reported. Note that it is not clear when current GIT source for sane-backends will reach Fedora.

Cheers,
Terry

I wonder if perhaps a library or libraries may have been missing.
-::-OR-::-
If the kernel list's 2 different drivers for the same device it can cause the device not to work.
If drivers conflict or wrong driver is loaded first.

Anyway; I'm glad your scanner is working now.

Basilicum · 11-18-2015, 01:47 PM

At date I am experiencing problems with the Epson 3490, running fc21 and fc22, both at least weekly updated.

I recognize the behaviour sketched in this tread. When I purchased the Epson 3490, Epson provided a scan program that worked excellent. Later on Epson did not maintain this program and after a few years one could not use it due to incompatibilities. However, one could load the firmware as described in this tread, and Sane did work good. After a while non reproducable problems started as described in this tread. Sometimes Sane worked flawlessly and sometimes I had to start Sane several times. On a root account it always worked, so I suspect policy kit. I did the permission for the group tric, but that did not solve these problems.

I did not experience the specific problem and solution described at the end of this tread.

Today was different. I think the firmware loaded almost completely, but than the whole thing crashes. In the same session I could not start Sane again or any other scan program. Some USB errors were reported one of them enumaretion. Surprisingly my scanner was reported as a 3590 instead of a 3490. I had to do a real cold boot (switching off mains) to return to a clean state.

The thing is that four days ago everything worked (despite the hindrances), but today it was totally different. My guess is that some package somewhere was changed or cleaned up that causes this, and I think it is somewhere in the USB corner. (both on fc21 and fc22).

I do not have myself the expertise to do debugging at a serious level, but if yum/dnf keeps a history track, than it must be a package that has been updated in some fews days prior to November 18th.

If you think it would help me and others to try to nail down the problem, please give me some instructions of what to do.

Basilicum