Re: direct solaris support

Martin Huber (hu@garfield.m.isar.de)
Wed, 28 Jan 1998 00:41:13 +0100 (MET)

>
> Hello. Are you guys planning to add direct solaris support? I have
> tried using that generic scsi module (scg) but I can not get it to do
> anything. Thanks.
>

Sane-Solaris is known to work with HP scanners (perfectly) and umax
(almost perfect: works, writing some annoying messages).

Others are not known, except of Microtek:
I borrowed a Microtek ScanMaker III and tested it with the
sg driver (this is not free, but I have the source-code).
I found, that this driver takes the user-scsi-structure it gets
from sanei_scsi_cmd, puts it's contents, together with other things,
into a struct scsi_pkt and gives it to the kernel routine scsi_transport().
This works fine for the commands defined in the SCSI spec.
But there are some reserved commands and some vendor-specific commands,
which are used by some scanners.

E.g. microtek uses the command 0x19 in the function mode_sense_1().
This command is vendor-specific for all devices except of magnetic tapes,
where it is ERASE, and there the fifth word of the cdb, where microtek
has the buffer size, is RESERVED.
Evidently the scanner behaves different upon this command than a tape,
and other than scsi_transport() expects. So it ignores this command, and
returns in pkt_reason
CMD_UNX_BUS_FREE = Unexpected Bus Free Phase occurred.

The scg driver logs 'handle incomplete: 1 ....' to the console upon this
command, so I assume, it does the same.

Other than for umax, where such a command could be removed, it seems to be
needed, though it transfers only 30 zeros to the scanner. If it is omittet,
the scanner never returns READY to a test_unit_ready command. Perhaps
Matthew has an idea? What does this command do, I have no description?

For a general solution, for all type of scanners, I fear, the solaris
kernel (scsi_transport) has to be changed.

The other problem are the annoing error messages seen by umax.
Joergs scg driver comes from a CD-Writer, and it write a warning message,
if a device does not respond ready to a test_unit_ready command.
Now we "abuse" it for a scanner, which is not ready while it is scanning.
These messages can be removed by changing scg, or reduced by asking the
scanning canner test_unit_ready less frequently (done in umax).

I think, we have to look at every backend to get it working.
I don't know how a 'direct solaris support' (without using the
scsi_transport kernel function) should look like.
Unfortunately, my scanner is HP and this is the simplest one (no strange
commands), so it is hard for me to debug.

--martin

--
Source code, list archive, and docs: http://www.mostang.com/sane/
To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com