Description of problem: Canon LiDE 110 flatbed scanner is not recognized and cannot be used. Version-Release number of selected component (if applicable): sane-backends-1.0.22-10.fc16.x86_64 How reproducible: Every time Steps to Reproduce: 1.Connect 2.run scanimage -L 3.run sane-find-scanner Actual results: $ scanimage -L No scanners were identified. If you were expecting something different, check that the scanner is plugged in, turned on and detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages). Expected results: $ scanimage -L device `genesys:libusb:001:002' is a Canon LiDE 110 flatbed scanner Additional info: Installing using the source from http://www.sane-project.org/source.html resolves the issue. As per a comment here https://bugzilla.redhat.com/show_bug.cgi?id=758964, the scanner works on Fedora 17
Had forgotten to add the sane-find scanner output: bash-4.2$ sane-find-scanner # sane-find-scanner will now attempt to detect your scanner. ... found USB scanner (vendor=0x04a9 [Canon], product=0x1909 [CanoScan], chip=GL124) at libusb:001:005 # Your USB scanner was (probably) detected. It may or may not be supported by # SANE. Try scanimage -L and read the backend's manpage.
According to that bug also, it's most likely a kernel issue. Closing as duplicate. *** This bug has been marked as a duplicate of bug 758964 ***
I filed it against sane-backends because by using the source from sane project site, it worked on Fedora 16. Had it been a kernel issue, it should not have worked.
(In reply to comment #3) > I filed it against sane-backends because by using the source from sane project > site, it worked on Fedora 16. Which is very odd because the available Fedora packages don't contain changes to the SANE core, nor the genesys backend over the 1.0.22 release. What source exactly did you use?
I was also puzzled. The source was https://alioth.debian.org/frs/download.php/3503/sane-backends-1.0.22.tar.gz I had made a careless error and used ./configure --prefix=/usr --sysconfdir=/etc I experimented with ./configure --prefix=/usr --sysconfdir=/etc --libdir=/usr/lib64 and it did not work! So, for some reason, sane-backends wants at least some libraries to be in lib and not lib64. That explains why it works in some distributions but not fedora.
Hmm. That could explain things. If possible, please try the following command with both working and non-working "versions" of your sane-backends installation, substituting a suitable file name for $outputfile: strace -Ff -o $outputfile scanimage -L Then attach both generated files to this bug report. Thanks!
Created attachment 586289 [details] strace of scanimage -L (Canon scanner is recognised)
Created attachment 586291 [details] strace of scanimage -L (Fedora 16 rpm's Canon scanner is not recognised) Note: this trace is from a netbook on which the sane-backend from source was not installed.
Very sorry - just noticed that sane-backends-drivers-scanners was not installed on the netbook. On the desktop, the scanner now works with the sane-backends from the fedora repository as well as with the sane-backends built in /usr/lib64. Some recent updates may have resolved the problem. If I was making a mistake, I wish I knew what it was :( Anil
This package not being installed explains your issue, but it's not really your fault. A bit of background: The scanner drivers were split off from the libraries as the latter are a dependency of the color management components at least in the GNOME desktop and we wanted to give people the option to not install the scanner drivers if they don't have a scanner. The package is installed per default with the GNOME, Graphics and Design Suite package groups, but at this time there's no way to "suggest" installing this along with the sane-backends library if you install it after installing your system, so right now you can end up with installing the library but not the drivers. If we ever get to the point of being able to specify some kind of "soft requirements" in RPM packages, this would be an ideal candidate. Sorry for the hassle.