Thomas> In mustek.c request_sense is called explicitly after some
Thomas> commands as indicated in Mustek's Control-Flow document. As
Thomas> far as I understand the SCSI drafts (SCSI-1, SCSI-2) the
Thomas> sense data are valid only for a limited number of cases,
Thomas> e.g. the command prior to request_sense returns
Thomas> CHECK_CONDITION. These cases are handled already by the
Thomas> low-level drivers in the kernel, so the additional
Thomas> request_sense issued by mustek.c cannot be guaranteed to
Thomas> retrieve valid sense data.
You're absolutely right.
Thomas> At least with the above mentioned combo scanning (NOT color
Thomas> scanning) works perfectly after inserting a dummy routine
Thomas> instead of request_sense.
Are you saying you're having problems with color scanning? I think
Andy has the same scanner type (slightly different firmware, though)
and I thought things work fine for him.
Thomas> Maybe a function for parsing sense data should be hooked
Thomas> directly to sanei_scsi_cmd, or the valid bit of sense data
Thomas> should be checked.
I'm downloading the SCSI specs as I'm writing this. I have some ideas
on how to handle this, but want to check the specs first.
Thomas> Please fix me if I'm wrong, but since it works for me now, I
Thomas> suspect, that the additional request_sense was in fact the
Thomas> source for my problems.
It works for my controller (ncr810) as well.
--david
-- Source code, list archive, and docs: http://www.azstarnet.com/~axplinux/sane/ To unsubscribe: mail -s unsubscribe sane-devel-request@listserv.azstarnet.com