Scanner setup, hiccup. Epson GT7000s OpenSuse 13.2
Hi All I have a SCSI scanner which normally "just works" under Linux. I have just loaded a fresh OpenSuse 13.2 (64bit) OS. The scanner is found in lspci and also in the hardware detection in Suse. For some reason XSANE cannot see it. When using the scanner setup tool in the YAST , it identifies the scanner but reports that the driver is not configured. The driver should be the sane-epson2. What am I missing, please? Andrew Greig
Hi Andrew. My scanner needs a firmware file to be downloaded and installed. Is this the same for Epson?. Although it has the driver (snapscan in my case), it still needs this firmware file - Mine is a Benq scanner (quite old). I often forget to install this file when I connect the scanner to a new PC and it will not be detected by sane without it, but will show in lsusb. Its possible too that I have had to install 32 bit libraries as well. Usually you will find more info on the sane website under supported device section. Cheers Daniel. On 24/05/15 23:54, Andrew Greig wrote:
Hi All
I have a SCSI scanner which normally "just works" under Linux. I have just loaded a fresh OpenSuse 13.2 (64bit) OS. The scanner is found in lspci and also in the hardware detection in Suse. For some reason XSANE cannot see it. When using the scanner setup tool in the YAST , it identifies the scanner but reports that the driver is not configured. The driver should be the sane-epson2. What am I missing, please?
Andrew Greig _______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
Quoting Andrew Greig (pushin.linux@gmail.com):
I have a SCSI scanner which normally "just works" under Linux.
Make is presumably Epson, but what's the model? Suggestion: Whenever seeking help with Linux support of hardware, it is extremely useful to provide accurate make/model data. (If you happen to have chipset identities, that is also good, but your helpers can determine those given accurate make/model data.) It might be that more than one SANE back-end is trying to support your scanner. Try temporarily commenting out the lines for 'epson' and 'epkowa' in /etc/sane.d/dll.conf , and trying again. More tips here: https://wiki.archlinux.org/index.php/Sane -- Cheers, C.S. Lewis fan: "I'd like to visit Narnia." Rick Moen Tolkien fan: "I'd like to live in Middle-Earth." rick@linuxmafia.com George R.R. Martin fan: "Nope, I'm good." McQ! (4x80)
On Sun, 2015-05-24 at 12:07 -0700, Rick Moen wrote:
Quoting Andrew Greig (pushin.linux@gmail.com):
I have a SCSI scanner which normally "just works" under Linux.
Make is presumably Epson, but what's the model? Suggestion: Whenever seeking help with Linux support of hardware, it is extremely useful to provide accurate make/model data. (If you happen to have chipset identities, that is also good, but your helpers can determine those given accurate make/model data.)
It might be that more than one SANE back-end is trying to support your scanner. Try temporarily commenting out the lines for 'epson' and 'epkowa' in /etc/sane.d/dll.conf , and trying again. More tips here:
Hey Rick, Haven't seen a post from you for ages, I am very glad that this thread brought you out. 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. Thanks Andrew Greig
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.
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. By the way I downloaded a trial version of Vuescan, a proprietary scanning front end which runs on Linux. It must be small as it took around 20 seconds to download, and the whole thing was self contained. I stuck it in my Downloads folder. Last night, before I had done the dll.conf thing, running of the binary, it found the scanner and was ready to go with a very slick, clean interface in seconds. Scan quality was very good but trial scans are heavily watermarked, and issue the invitation to buy the full versions. A very nice piece of work. Thanks again Andrew Greig
Quoting Andrew Greig (pushin.linux@gmail.com):
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.
Yeah, that would do it. ;-> Glad you got to the bottom of that, though one wonders _what_ disabled all SANE back-ends.
By the way I downloaded a trial version of Vuescan, a proprietary scanning front end which runs on Linux. It must be small as it took around 20 seconds to download, and the whole thing was self contained. I stuck it in my Downloads folder. Last night, before I had done the dll.conf thing, running of the binary, it found the scanner and was ready to go with a very slick, clean interface in seconds. Scan quality was very good but trial scans are heavily watermarked, and issue the invitation to buy the full versions. A very nice piece of work.
Yes, Vuescan has an excellent reputation, and I've often recommended it for users of scanners unsupported (or poorly supported) by SANE. As with other categories of proprietary drivers, Vuescan has the advantage that its maintainer (Hamrick Software) can sign NDAs to get access to secret manufacturer-confidential chipset information, instead of needing to reverse-engineer that information or glean it from public information, as open source coders are obliged to do. So, inherently, they have an information advantage in coding for the problem cases. Additionally, they have a financial incentive to develop support even for obscure hardware that open source coders would try _not_ to own and have no compelling personal interest in supporting. Personally, on the rare occasions when I end up with hardware with really poor or nonexistent open source driver support, I interpret that as an indicator of undesirable hardware, sell it, and get something better. Your Mileage May Differ.[tm]
On 05/27/2015 04:38 AM, Rick Moen wrote:
Quoting Andrew Greig (pushin.linux@gmail.com):
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. Yeah, that would do it. ;->
Glad you got to the bottom of that, though one wonders _what_ disabled all SANE back-ends.
By the way I downloaded a trial version of Vuescan, a proprietary scanning front end which runs on Linux. It must be small as it took around 20 seconds to download, and the whole thing was self contained. I stuck it in my Downloads folder. Last night, before I had done the dll.conf thing, running of the binary, it found the scanner and was ready to go with a very slick, clean interface in seconds. Scan quality was very good but trial scans are heavily watermarked, and issue the invitation to buy the full versions. A very nice piece of work. Yes, Vuescan has an excellent reputation, and I've often recommended it for users of scanners unsupported (or poorly supported) by SANE. As with other categories of proprietary drivers, Vuescan has the advantage that its maintainer (Hamrick Software) can sign NDAs to get access to secret manufacturer-confidential chipset information, instead of needing to reverse-engineer that information or glean it from public information, as open source coders are obliged to do. So, inherently, they have an information advantage in coding for the problem cases. Additionally, they have a financial incentive to develop support even for obscure hardware that open source coders would try _not_ to own and have no compelling personal interest in supporting.
Personally, on the rare occasions when I end up with hardware with really poor or nonexistent open source driver support, I interpret that as an indicator of undesirable hardware, sell it, and get something better. Your Mileage May Differ.[tm] I really appreciate this conversation, as it answers a question which I planned to ask. So for the sake of completeness, here was my unasked question. Which I preface with this comment that up until OpenSuse 13.2 every Linux system I have loaded has "just worked" out of the box with the GT7000S. I was told that this was because SCSI and Linux fit like hand in glove.
My question was how can a proprietary product, completely stand-alone in my ~/ , load in seconds, and discover the SCSI card in seconds, and be ready to work? Xsane, when installed into a running machine has always needed a reboot to start working. In fact if I cancel a scan (I have learned not to do this) Xsane will not even find the scanner until I reboot. This provokes another question, how do I avoid the reboot to get a SCSI scanner working again? Is there such a thing as stopping and starting a SCSI process? Thanks again Andrew Greig
On 27/05/15 23:10, Andrew Greig wrote:
This provokes another question, how do I avoid the reboot to get a SCSI scanner working again? Is there such a thing as stopping and starting a SCSI process?
Yes, you can rescan a SCSI bus with: echo "- - -" > /sys/class/scsi_host/$HOST/scan Where $HOST will typically be host0, host1 etc. depending how many SCSI hosts (including ATA) you have. This is very useful if you have SCSI hotplug hard drives, or external SCSI devices that you power on and off! Hope that helps, Andrew -- mailto:xanni@xanadu.net Andrew Pam http://www.xanadu.com.au/ Chief Scientist, Xanadu http://www.glasswings.com.au/ Partner, Glass Wings http://www.sericyb.com.au/ Manager, Serious Cybernetics
Quoting Andrew Greig (pushin.linux@gmail.com):
My question was how can a proprietary product, completely stand-alone in my ~/ , load in seconds, and discover the SCSI card in seconds, and be ready to work? Xsane, when installed into a running machine has always needed a reboot to start working. In fact if I cancel a scan (I have learned not to do this) Xsane will not even find the scanner until I reboot. This provokes another question, how do I avoid the reboot to get a SCSI scanner working again? Is there such a thing as stopping and starting a SCSI process?
Here's more information about SCSI rescanning in Linux: http://linoxide.com/how-tos/linux-scan-scsi/ Quite possibly, Vuescan includes wrapper code to trigger a rescan at the time of program startup. I haven't personally needed to do scanning on Linux (or, frankly, any other OS) in far more years than I'd really like to think about. At the time I last did, I used whatever was then common on Linux and an old SCSI-based flatbed scanner. It worked in the routine way one would hope and expect, and I certainly never had to reboot just to make the software find the device.
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.
On Wed, May 27, 2015 at 01:04:50PM +1000, Allan Duncan wrote:
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.
the benefit would be that some scanners may not work if certain drivers are loaded or are loaded in the wrong order (e.g. newer or older models or almost-but-not-quite-100%-clone brands that require a specific driver rather than a generic driver for that brand), and this is a lot harder and far more confusing to diagnose (because the logs indicate that a driver was successfully loaded) than no drivers being loaded at all, which is easily fixed just by googling for "sane +brand +model" sometimes it's best NOT to configure anything at all by default and leave it up to the user to know what's in their system, or just assume that they have at least moderate intelligence and are capable of using google.
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.
sometimes - perhaps even most of the time - auto-detect/auto-configure tools work brilliantly. and sometimes they just fuck things up...and they usually do that in a way which hides or disguises what the problem is. craig -- craig sanders <cas@taz.net.au>
participants (6)
-
Allan Duncan -
Andrew Greig -
Andrew Pam -
Craig Sanders -
Daniel Jitnah -
Rick Moen