> Now for the backend problem at hand: I could of course do those sg ioctl's
> in the backend, but that should rather be done by sane, not by the
> backends. Do you perhaps know whether there are any development plans for
> sane to include support for such ioctl's?
If you need a quick fix, you might try Douglas's SG driver version 3
(http://www.torque.net/sg) in combination with the modifications to
sanei_scsi.c which I posted some weeks ago on this mailing list. While
these modifiactions were mainly intended to benefit from other
improvements in the SG driver (it is possible to omit a buffer in
sanei_scsi.c for the data read from the scanner), they should also fix
the problem, that the SG driver must guess the length of SCSI commands.
(Douglas, please correct me if I am wrong, but I think that with the new
header structure, the SG driver takes the length of the SCSI command
from sg_io_hdr.cmd_len.)
On the other hand, I am not that sure about the origin of the problem
with the Canon scanner: get_scan_mode in canon_scsi.c uses a command
buffer of length 10 (at least the version included in sane-1.0.1). So
the command length see by the SG driver should be anyway 10 bytes. But
then again, there is a comment line in this function "/* static u_char
cmd[6] */"...
Abel
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com