jafo@tummy.com said:
> I sent a query to Leonard Zubkoff asking for his opinion, and he says
> that the code appears to work that way. I haven't had a chance to
> try it with the BusLogic drivers that he authors yet though. It
> looks like the:
> if (req->cdb.hdr.result == 0 && (req->cdb.hdr.sense_buffer[0] &
> 0x7f) == 0)
> needs to be changed to:
> if (req->cdb.hdr.result == 0)
> for SANE to work on NCR, DPT, and some AHA systems.
This will not work with all scanners, e.g. the coolscan. Problems
only occur with those backends which are not prepared to be called
with information in the sense buffer but with a 0 result. That is a
problem with the backends though, not with the code above (IMHO).
Almost, for both of you....
As I detailed before, the problem breaks down into:
o some scsi low-level drivers (i.e. aha152x and prob. NCR, etc)
will automatically send a REQUEST_SENSE in response to CHECK_CONDITION.
That's a-ok by itself, but,
o some scanners (i.e. Microtek) return non-standard sense information,
which some scsi drivers choose to ignore.
Also, ok (marginally, and the fact that the sg driver doesn't return
all of the status/suggestions sent by the low-level drivers is just
unforgivable), but,
o when the sanei_scsi code detects the presence of any sense information,
it turns the situation into an unrecoverable error.
Not ok, because some scanners (i.e. Microtek) generate some unnecessary
CHECK_CONDITIONs under predictable but unavoidable situations.
Really, this is Microtek's fault, but it's also not Linux-specific.
That last snag has been fixed in the current SANE pre-release.
-matt m.
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com