Wolfgang Rapp wrote:
>
> abel deuring wrote:
>
> >
> >
> > I agree, that the small time window for sending a "read" command after
> > finishing the previous read and not having the scan head stop is indeed
> > the main cause for scan heads stops -
>
> I think this is exactly the main point and I am able to compare .
>
> Before I did the Unixware 2 port of sane I wrote a driver for Microtek
> Scanmaker.
> In this solution the whole scanning loop was inside the driver and the
> application
> set up one read command for the whole scan. This driver runs mutch more
> faster
> than the sane solution with minimum head stops. It only stops if the
> application must
> swap the huge allocated memory on the same SCSI controller. Mutch more
> better if the
> swap is on a IDE disk or seperate controller.
>
> If I recogmized it well , all backends send a lot of times the same
> SCSI-Command block with
> following read system call. Is it right that only the last Command differs
> in most cases?
> So the only solution could be that the backends tell sanei_scsi how
> often a certain
> SCSI-Command should be executed and sanei_scsi decides what to do on the
> different
> platforms and alloc the memory. It's clear that this needs special sane
> drivers for every platform
> if the scan should be as fast as possible but don't prevent using the
> current method if no special
> driver is available In my opinion this is the only way to speed up scans
> and avoid head stops.
> What could happen that we can't cancel a scan so easy because we only may
> interrupt system calls
> by signals. But we can send a SIGALRM to do this.
I think, there already exists a mechanism in sanei_scsi.c, the function
pair sanei_scsi_req_enter (send a SCSI command to the scanner) /
sanei_scsi_req_wait (wait for the results of the command).
Unfortunately, they are at present only for Linux implemented in "real"
way; for the other OS, sanei_scsi_req_enter simply calls sanei_scsi_cmd,
and sanei_scsi_req_wait is empty.
But there are some scanners, for which the queueing does not seem to
help: I pplayed a little bit with an old Mustek scanner (sorry, I don't
know the exact type; it was sold in Germany under the brand name
"Network", and the inquiry command did not tell me anything I could
recognise as a model specification...) The Mustek backend already
supports queueing, therefore I hoped that my patches to the Linux
queueing might help to avoid some scan head stops, but I had no luck. I
guess that the scanners's firmware is a little bit stupid, and stops
after every "read scan data" command. With such a scanner, the only way
to improve the scan speed is to use large buffers.
Abel
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
This archive was generated by hypermail 2b29 : Fri Feb 04 2000 - 03:56:56 PST