backend for sharp-scanners
Please send comments, bug reports and bug fixes to
Abel Deuring, or
Kazuya Fukuda, or to the
Sane developer mailing
list.
For general information on Sane, please see http://www.mostang.com/sane/
For other Sharp scanners, it may or may not work.
specialWhere special is either the path-name for the special device that corresponds to a SCSI scanner. The special device name must be a generic SCSI device or a symlink to such a device. Under Linux, such a device name could be /dev/sga or /dev/sge, for example. See sane-scsi(5) for details.
The scan window parameters are:
Lines setting an option start with the key word option, followed by the option's name and the option's value. At present, three options are defined: buffers, buffersize, and readqueue.
Options defined at the start of sharp.conf apply to all devices listed in this file; options defined after a device name apply to this device.
The options buffers and readqueue are only significant if the backend has been compiled so that for each scan a second process is forked (switch USE_FORK in sharp.c). This process reads the scan data from scanner and writes this data into a block of shared memory. The parent process reads the data from this memory block and delivers it to the frontend. The options control the size and usage of this shared memory block.
option buffers defines the number of buffers used. The smallest number allowed is 2.
option buffersize defines the size of one buffer. Since each buffer is filled with a single read command sent to the scanner, its size is limited automatically to the size allowed by the operating system or by the Sane SCSI library for SCSI read commands. A buffer size of 128 kB or 256 kB is recommended for scan resolutions of 300&dpi and above.option readqueue defines how many read commands to be sent to the scanner are queued. At present, the Sane SCSI library supports queued read commands only for for Linux. For other operating systems, option readqueue should be set to 0. For Linux, option readqueue should be set to 2. Larger values than 2 for option readqueue are not reasonable in most cases. option buffers should be greater than option readqueue.
Even the JX-250 needs only less than 10 seconds for a 400 dpi A4 gray scale scan, which results in a data transfer rate of more than 1.6 MB per second. This means that the data produced by the scanner must be processed fairly fast. Due to the small internal buffer of the JX-250, the backend must issue a read request for the next data block as soon as possible after reading a block of data in order to avoid carriage stops.
Stops of the carriage can be caused by the following reasons:
Too much "traffic" on the SCSI bus: This happens for example, if hard disks are connected to the same SCSI bus as the scanner, and when data transfer from/to these hard disks requires a considerable part of the SCSI bandwidth during a scan. If this is the case, you should consider to connect the scanner to a separate SCSI adapter.
Slow responses by the backend to the scanner: Unfortunately, Unix-like operating systems generally have no real time capabilities. Thus there is no guarantee that the backend is under any circumstances able to communicate with the scanner as fast as required. To minimize this problem, the backend should be compiled so that a separate reader process is forked: Make sure that USE_FORK is defined when you compile sharp.c. If slow responses of the backend remain to be problem, you could try to reduce the load of the system. Even while the backend and the reader process need only a minor amount of processor time, other running processes can cause an increase in the time delay between two time slices given to the reader process. On slower systems, such an increased delay can be enough to cause a carriage stop with the JX-250. For Linux, the usage of the SG driver version 2.1.36 or above is recommended, because it supports, in combination with the SCSI library of Sane version 1.0.2, command queueing within the kernel. This queueing implementation, combined with a buffer size of at least 128 kB, should avoid most carirage stops.
Slow processing of the scan data: An example for this situation is the access to the scanner via a 10 MBit Ethernet, which is definitely too slow to transfer the scan data as fast as they are produced by the scanner. If you have enough memory available, you can increase option buffers, so that an entire image can be stored in these buffers.
In order to see, if the backend is too slow or if the further processing of the data is too slow, set the environment variable SANE_DEBUG_SHARP to 1. When a scan is finished, the backend writes the line "buffer full conditions: nn" to stderr. If nn is zero, carriage stops are caused by too slow responses of the backend or too much "traffic" on the SCSI bus. If nn is greater than zero, the backend had to wait nn times until a buffer has been processed by the frontend. (Please note that option buffers must be greater than option readqueue in order to get useful output for "buffer full conditions".)
For a more detailed discussion of the influence of command queueing and buffer size on the scan performance, see here.
Parts of the man page are a plain copy of sane-mustek(5) by David Mosberger-Tang, Andreas Czechanowski and Andreas Bolsch.
Kazuya Fukuda
Abel Deuring
Last modified: Nov 21 2000