Fetching latest commit…
Cannot retrieve the latest commit at this time.
|Failed to load latest commit information.|
$OpenBSD: README.ss,v 1.5 1997/03/11 03:40:49 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. 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 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. Other Considerations SCSI disconnect is missing from many scanners. Sucks huh? A slow peripheral that also monopolizes the bus. This means that if your scanner does not support disconnect you need a second SCSI controller for it since access of the controller by any other devices will be locked out while you are scanning. Scanners that do this include MUSTEK flatbed scanners MFS 06000CX and MFS 12000CX, UMAX UC-630 & UG-630. Over time, as multi-tasking becomes more important to commoners^H^H^H^H^H^H^H^H^HWindoze users, scanner vendors often supply new ROMs that can do disconnect. The image data from the scanner driver is currently supposed to resemble headerless PBM "rawbits". Depending on this is probably a bad idea especially because it cannot always be attained. The Fujutisu M3096G grayscale data is photo-negative with repect to PBM and this cannot be changed. It would be better to extend the ioctl() interface to be able to describe the kind of data that is available. Halftone control of scanners is missing, save for one pre-defined selection. This also should be in the ioctl() interface. Basic workflow for scanning 1. Open driver. 2. ioctl to get parameters (this fills in default values and generally makes step 3 easier.) 3. Modify parameters. 4. ioctl to set parameters. 5. ioctl to get data size (same as step 2, but values will be different if the image size, resolution, or image data type was set.) 6. Read data based on size from scanner retrieved in step 5 (the driver delivers an EOF if you overread.) 7. Close driver (or use ioctl to reset it so you can scan again.)