[sane-devel] Fwd: Nikon Coolscan II LS20

Henning Meier-Geinitz henning@meier-geinitz.de
Thu, 30 Oct 2003 09:19:16 +0100


On Wed, Oct 29, 2003 at 10:13:55PM +0100, Franz Bakan wrote:
> here a question/problem from a user of a Nikon LS20.

I guess that's on OS/2?

> Nikon Coolscan II alias LS20 works fine with sane 1.0.5 and Tame 
> But I have some problems with this scanner and sane 1.0.12. Prescan aborts after some 
> bytes. Scan does not work too. I think there is a problem with the SCSI commands sent 
> by the backend.

The coolscan backend hasn't been changed significantly between sane
1.0.5 and sane 1.0.12. In fact it's unmaintained for a long time now.
I don't remember any similar bug report for that scanner on a Unix
system, however.

> I use ASPI 1.1beta9 and tried with two different SCSI adapters, NCR810 and Adaptec 
> 2940. 1.0.5 works fine with both adapters but 1.0.12 and 1.0.11 make troubles. 

The coolscan backend uses fork() and a reader process with two
parameters. Maybe that's a problem? Maybe 1.0.5 was compiled in a
different way concerning fork?

> The reason I would like to switch from 1.0.5 to a newer sane version is because of the 
> limit in the length of the parameters that can be passed to scanimage. With Tame 
> 1.0beta I sometimes exceed 540 characters, which causes scanimage to fail.

Can you explain that in more detail? Does it fail because one
parameter is too long or because the command line itsself is too long?
What's the error message?

I've just tested scanimage with lots of options (test backend). I got
a line of > 1000 characters and scanning worked without problems.

I'll attach it.

> Where should I trace to find the reason for coolscan not working with sane 1.0.12?

Generally speaaking, you can enable debug messages by setting
environment variables. E.g. for bash:
export SANE_DEBUG_SCSI=255

But I don't know how detailed these messages are.

> How can I overcome the length limit of the parameters. Is it a limit of scanimage or 
> libsane.dll? 

I don't think that SANE has such a limit at all. Maybe an OS/2 (or
shell) limitation? scanimage uses getopt for getting options. Maybe
that's the reason?



scanimage -d test:0 --format=pnm --batch-count=2 --verbose \
  -l 0 \
  -t 0 \
  -x 100 \
  -y 100 \
  --mode Color \
  --depth 8 \
  --hand-scanner=no \
  --three-pass=no \
  --resolution=300 \
  --test-picture="Grid" \
  --read-limit=no \
  --read-delay=yes \
  --read-delay-duration 1000 \
  --read-return-value=Default \
  --ppl-loss=0 \
  --fuzzy-parameters=no \
  --non-blocking=no \
  --select-fd=no \
  --enable-test-options=yes \
  --bool-soft-select-soft-detect=no \
  --bool-soft-select-soft-detect-emulated=no \
  --bool-soft-select-soft-detect-auto=auto \
  --int=1 \
  --int-constraint-range=5 \
  --int-constraint-word-list=-42 \
  --int-constraint-array-constraint-range=4,6,8 \
  --int-constraint-array-constraint-word-list=0,17,42 \
  --fixed=0.123 \
  --fixed-constraint-range=32.5 \
  --fixed-constraint-word-list=12.1 \
  --string=Hubba \
  --string-constraint-string-list="Second entry" \
  --string-constraint-long-string-list="First entry" \
  --button \
  > /tmp/image.pnm