[sane-devel] FreeBSD and Microtek Scanmaker II

[Matto Marjanovic]

Hi,

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] .stop_scan...
 >[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
 >[microtek] sane_start...
 >
 >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.

-matt m.