diff options
author | 1997-03-08 21:23:42 +0000 | |
---|---|---|
committer | 1997-03-08 21:23:42 +0000 | |
commit | 5e45b8b2a9b9b724be302c4c47f7f09c4115e4ef (patch) | |
tree | 591f7bf3a47c67276f427b4f6547cecea786015b | |
parent | some scanner driver docs (diff) | |
download | wireguard-openbsd-5e45b8b2a9b9b724be302c4c47f7f09c4115e4ef.tar.xz wireguard-openbsd-5e45b8b2a9b9b724be302c4c47f7f09c4115e4ef.zip |
reformatted text
-rw-r--r-- | sys/scsi/README.ss | 48 |
1 files changed, 23 insertions, 25 deletions
diff --git a/sys/scsi/README.ss b/sys/scsi/README.ss index 88603af1b12..d88bd836b21 100644 --- a/sys/scsi/README.ss +++ b/sys/scsi/README.ss @@ -1,35 +1,33 @@ -$OpenBSD: README.ss,v 1.1 1997/03/08 21:21:37 kstailey Exp $ +$OpenBSD: README.ss,v 1.2 1997/03/08 21:23:42 kstailey Exp $ If you think SCSI tape drives are quirky you haven't seen anything. -There are many SCSI scanners that don't use the SCSI Scanner protocol -with CDB's like SET_WINDOW. Instead they send Esc-code sequences over -the SCSI bus using the READ and WRITE operations. True brain death at -its finest. The HP ScanJet, the Sharp JX-600S and the Epson ES-300C -are among these. +There are many SCSI scanners that don't use the SCSI Scanner protocol with +CDB's like SET_WINDOW. Instead they send Esc-code sequences over the SCSI +bus using the READ and WRITE operations. True brain death at its finest. +The HP ScanJet, the Sharp JX-600S and the Epson ES-300C are among these. -Ricoh, UMAX, Mustek, Fujitsu, Microtek on the other hand all try to -use the SCSI scanner protocol, but scanning, unlike reading a block -from a disk, is a multi-step operation. Certain steps must be -performed in sequence and the protocol does not define this. In -addition vendors are permitted by the SCSI spec. to have unique -additional features that the spec. does not fully define. Last but not -least vendors make mistakes in implementing the spec. +Ricoh, UMAX, Mustek, Fujitsu, Microtek on the other hand all try to use the +SCSI scanner protocol, but scanning, unlike reading a block from a disk, is +a multi-step operation. Certain steps must be performed in sequence and +the protocol does not define this. In addition vendors are permitted by +the SCSI spec. to have unique additional features that the spec. does not +fully define. Last but not least vendors make mistakes in implementing the +spec. My SCSI scanner driver architecture is designed to support scanners two ways. -The first way is used if a scanner uses CDB's like SET_WINDOW. The -driver code should be in ss.c and quirk tables and sequence strings -etc. can battle it out. This part is not fully implemented yet. -Work is being done on it from time to time. +The first way is used if a scanner uses CDB's like SET_WINDOW. The driver +code should be in ss.c and quirk tables and sequence strings etc. can +battle it out. This part is not fully implemented yet. Work is being done +on it from time to time. -The other way is used when the driver is used with an -Esc-code-over-SCSI case like a ScanJet it installs an "operations -switch" so that parts of the code in ss.c can be bypassed. This -feature is implemented for ScanJets. Currently some Mustek scanners -use this approach, as the Mustek scanners use MODE_SELECT and not -SET_WINDOW to send parameter data. However it is possible that too -much code was farmed out to ss_mustek.c; it may be that common code -for ssread() in ss.c could be used. +The other way is used when the driver is used with an Esc-code-over-SCSI +case like a ScanJet it installs an "operations switch" so that parts of the +code in ss.c can be bypassed. This feature is implemented for ScanJets. +Currently some Mustek scanners use this approach, as the Mustek scanners +use MODE_SELECT and not SET_WINDOW to send parameter data. However it is +possible that too much code was farmed out to ss_mustek.c; it may be that +common code for ssread() in ss.c could be used. |