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.
Greetings Wolfgang
-- 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 : Thu Feb 03 2000 - 13:11:27 PST