[sane-devel] FreeBSD and Microtek Scanmaker II
Wed, 18 Jun 2003 13:30:09 -0400
Sorry to get into this thread so late...
I have to pull out all my microtek notes again; I might even already have
a fix for this problem in the works --- a big graduation got in the way,
and now I have to refresh many memories.
But, in the meantime...
0) None of this generation of Microtek scanners supports SCSI disconnect.
Disconnect needs to be disabled for the scanner device (if not the
whole bus), and you should expect the scanner to monopolize the entire
bus during a scan.
1) The firmware in the earlier Microtek scanners is particularly brain-dead
with regards to timeouts like this. Even worse, I have pretty extensive
documentation from Microtek --- *but every scanner deviates from the
documented behavior in some important way*. Ugh.
2) With regards to this:
>Looking through the log, it seems to me that something is wrong in
>sanei_scsi.c. From your log file:
>[microtek] SPS:1b 0 0 0 0 0
>[sanei_scsi] sanei_scsi_cmd: scsi returned with status 10
>[microtek] SENSE! fd = 0
>[microtek] sense = 00 00 00 00.
>scanimage: min/max graylevel value = 21/255
>The "stop scan" command returns an error (the "sanei_scsi" line), and
>all following SCSI commands return errors too.
The scanner probably *is* generating a SENSE error along with sense info.
However, it is not a SCSI-2 device --- it follows SCSI-1-CCM (something
like that) and it generates non-standard sense codes.
I don't know about FreeBSD, but the Linux SCSI drivers always zero out
the sense codes --- this frustrates me to no end. The Linux drivers are
trying to be clever, but they assume that *every* device is SCSI-2, and
since the codes do not conform to SCSI-2, they get squashed.
Probably, FreeBSD is doing the same thing. What both OS's *should* do
is just pass the poor sense codes up to the sense handler installed by
the backend, which should be smart enough to deal with them. Instead,
the sense handler always gets called with a bunch of zeros!
3) For 3-pass scans, the backend needs to implement some kind of delay
between passes. *However*, because of
o the loss of the actual sense information
o the poor documentation
it is unclear which commands can be sent during that delay, if that
delay can be polled (i.e. ask the scanner if it is ready) or if it
must be guessed, etc, etc.
This is the part of maintaining this backend that I despise.
I'll start rummaging through my notes. I'm recollecting now that I had a
quick fix for this a couple of months ago --- but it was too late for the
release back then, and then I got really really busy.