Rainer Krienke wrote:
> Before I used the old sg driver with a patch that uses a static buffer
> of 1MBytes in size. This prevents the sg driver of beeing used as a
> module but has a really great effect in scanning time. To scan a DINA4
> page in 300 DPI color mode then takes only 45 seconds. Compared to the
> new sg driver this is about 4 times faster and after all it probably
> will be good for the scanner hardware itself as well (it needs do to
> backtracking only about 5 times compared to >20 times using the new
> driver).
>
> Wouldn´t it be possible to include such a static buffer (optional) in
> the new sg driver as well? The best new driver doesn't help, if you
> actually cannot use it in real live and as you can see from the examples
> avove this is true for the current situation.
While I have never thought much about internals of kernel programming, I
think that there should be better ways to avoid scanner carriage stops
than to increase the size of an SG-buffer.
sanei_scsi.c has already "its part" of an implementation of asynchronous
SCSI commands (sanei_scsi_req_enter and sanei_scsi_req_wait); and even
while their Linux implementation is only a "fake", the use of these
functions reduced the number of carriage stops with the Sharp JX250
scanner dramatically.
This suggests that most if not all scanner carriage stops can be avoided
if consecutive reads commands are sent to the scanner as soon as
possible after the data from the previous command has been read in.
Doug, what do you think about adding ioctl-calls to the SG driver which
implement queueing of asynchrounous SCSI commands?
Abel
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com