Using scanner with FreeBSD. A nightmare!

Thu Jun 10 15:39:07 PDT 2004

On Thursday 10 June 2004 13:15, Rob wrote:
> Olaf Hoyer wrote:

>
> > I think the warm-up of the device is a bit slow, before it actually will
> > do something.
>
> I find it so terribly slow in comparison to its operation on Windows,
> that I think it's not the HP scanner, but the software, or the way
> I use the software.
>
> Also the quality is miserable. Although that is probably my mistake,
> I use the software with its default settings. It should be strange
> that the defaults result in miserably low quality pictures....
>
> I have changed the scan from "Lineart" to "Color"; this allows me to
> have a long, long coffee break until the scan is finished!
>
> ------------
>
> One more thing I do not understand: I always have to give
> "hp:/dev/uscanner0" as the device parameter to the scanner command.
>
> When I do "xscanimage", I get
>   [xscanimage] No scanners were identified. If you were expecting something
>            different, check that the scanner is plugged in, turned on and
>            detected by sane-find-scanner (if appropriate). Please read
>            the documentation which came with this software (README, FAQ,
>            manpages).
>
> But "xscanimage hp:/dev/uscanner0" works fine.
>
> However, "sane-find-scanner", returns the scanner, vendor, product etc:
>      found USB scanner (vendor=0x03f0, product=0x0401) at /dev/uscanner0
>
> And "scanimage -L" returns:
>    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).

I did some debugging on that on 5.2-current with sane-backends 1.0.14.
I only have a HP-6270C, but it shows symptoms similar to your HP-5200C.   
The USB Controller is a VIA 83C572 chipset. I used xsane when debugging the hp 
driver. 

Scenario I.

1. Scanner attached to /dev/usb1.
2. Run xsane, xscanimage and friends under an unprivileged user.
3. Don't want to pass the [driver:/device] parameter to your scanner app. 

What happens?

The initialization code steps thru the usb devices until it finds a device 
that matches a driver:device in /usr/local/etc/sane.d/.
If a permission for a /dev/usbx device is missing and no matching device could 
be found, the initialization code calls sane_exit and the program terminates.  
[simply spoken]

So, if our scanner is attached to /dev/usb1 one need to set "proper" 
permissions on /dev/usb0, /dev/usb1 and /dev/uscanner0.

	crw-rw----  1 root  operator  243, 255 Jun  6 14:10 usb
	crw-rw-rw-  1 root  operator  243,   0 Jun  6 14:10 usb0
	crw-rw-rw-  1 root  operator  243,   1 Jun  6 14:10 usb1
	crw-rw----  1 root  operator  243,   2 Jun  6 14:10 usb2
	crw-rw----  1 root  operator  243,   3 Jun  6 14:10 usb3
	crw-rw-rw-  1 root  operator  242,   0 Jun 10 19:31 uscanner0

Scenario II.

1. Scanner is attached to /dev/usb1.
2. Run xsane, xscanimage and friends under an unprivileged user.
3. Pass the [driver:/device] opt to your scanner app. (ie. hp:/dev/uscanner) 
4. Modes of /dev/usb* /dev/uscanner0:

	crw-rw----  1 root  operator  243, 255 Jun  6 14:10 usb
	crw-rw----  1 root  operator  243,   0 Jun  6 14:10 usb0
	crw-rw-rw-  1 root  operator  243,   1 Jun  6 14:10 usb1
	crw-rw----  1 root  operator  243,   2 Jun  6 14:10 usb2
	crw-rw----  1 root  operator  243,   3 Jun  6 14:10 usb3
	crw-rw-rw-  1 root  operator  242,   0 Jun 10 19:31 uscanner0

What happens here?

The great difference here is that /dev/usb0 is left at default mode 660.
In general, modes 666 for /dev/usb1 and /dev/uscanner0 are sufficient, but 
device handling by the driver is different. It looks like the driver doesn't 
keep the device open (which it does in scenario I.):   

[hp] hp_GetOpenDevice: device /dev/uscanner0 not open
[hp] hp_nonscsi_open: device /dev/uscanner0 opened, fd=24
[hp] hp_AddOpenDevice: /dev/uscanner0 should not be kept open

Sometimes when the driver issues a scsi_flush to the scanner the scanner/app 
hangs for several minutes. Normally such large delay only occurs as a result 
of i/o errors, but not during normal operation (as under scenario I.).        

[hp] scsi_flush: writing 2 bytes:
[hp]  0x0000  1B 45                                            .E
[waits several minutes here]

Furthermore setting environment SANE_DEFAULT_DEVICE to "hp:/dev/uscanner0"  
does not work for xsane and xscanimage. According to the manpages it should 
work.

What can you do?

A simple way to make your scanner work without the devicename, is to plug the 
scanners usb cable into usb port 0 and do a 'chmod 666 /dev/usb0'. This 
should make your gimp-plugin happy.

In my mind scanner initialization runs faster and more stable, if the device 
stays open (as in scenario I.). You can make startup initialization a little 
faster by removing unneeded drivers from /usr/local/etc/sane.d/dll.conf. The 
line 'hp' should suffice.

Hint: Dust on the optical device also can slow down or break the calibration 
process of your scanner.

>
> Is there a configuration file where I should define the default scanner,
> i.e. "hp:/dev/uscanner0" ?

See SANE_DEFAULT_DEVICE above. 

>
> A side effect of this is (I believe), that sane doesn't work as a plugin
> with Gimp. I think Gimp first tries to probe the scanner devices, it
> doesn't get any, so the plugin doesn't work. Or something like this.
> (Yes, I have compiled sane with "WITH_GIMP=yes").
>
> Thanks for the help.
> Rob.
>

-- 
Christian Hiris <4711 at chello.at> | OpenPGP KeyID 0x941B6B0B 
OpenPGP-Key at hkp://wwwkeys.eu.pgp.net and http://pgp.mit.edu

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20040611/b1f191af/attachment.bin