On 26/05/15 23:30, Andrew Greig wrote:
On 05/26/2015 05:53 AM, Rick Moen wrote:
Quoting Andrew Greig (pushin.linux@gmail.com):
Absolutely correct! Machine is an Epson GT7000S for SCSI. The aix scsi drivers are loaded as always. Where I struggle with this one is that this is the first time in 9 years that this scanner has not "just worked" after a new install. I have this niggling thought in the back of my mind that it may be a group membership issue. But what group? And it doesn’t work as root. Well, come to think of that, the best way of testing (and eliminating) the 'It's a group or ownership issue' hypothesis is to see if it works as root, because then you're wielding root:root authority. However, FWIW, some ways of dealing with permission issues are covered at https://wiki.archlinux.org/index.php/Sane#Permission_problem .
'epson2' is of course the optimal choice of SANE back-ends for your GT-7000S scanner, and there's definitely no need for a firmware blob for it. Have you tried commenting out back-ends other than the desired epson2 one in /etc/sane.d/dll.conf ? For testing purposes, I'd try commenting out all other lines.
Hi Rick, Thanks for that tip. The dll.conf file had everything commented out, so all I had to do was lose the hash in front of the epson2 entry. This was the change which allowed XSANE to find the scanner and load the program. When it comes time to hook up my HP multifunction device I will certainly keep it in mind.
This will be down to how your Distro deals with configuration files. On an RPM based system the norm is if the file has been altered from the original, to leave the old one in place and put an ".rpmnew" suffix on the replacement. A clean install ofcourse bypasses that, and it appears your new install has aquired a change in policy, maybe to blacklist all and leave the end user to enable just the one they have. I can't see the benefit of this - my Canon is handled by the pixma driver, non-obvious. All this prompted me to look at my Fedora install which has most backends enabled, but the USB-based recognition uses the <manuf:device> ID. I don't know how the SCSI side would establish which backend is needed, although clearly it does.