Re: SANE and Mustek MFC-600S

David Mosberger-Tang (David.Mosberger@acm.org)
Sat, 6 Sep 1997 11:20:13 -0700

>>>>> On Fri, 29 Aug 1997 16:53:07 -0400 (EDT), jklaas <jklaas@ix.netcom.com> said:

James> I have a question about how sane goes about aquiring a scan
James> from the Mustek single pass scanners. Why does it seem to do
James> so much back tracking? When I scan in Windows no matter how
James> high the resolution I set, it just goes in one single run.
James> Where SANE seems to take a little bit at a time and then go
James> back and do that plus a couple of pixels more. All the way
James> up the end of the scan. It seems to take forever. Well, one
James> of the options to set was in backend/mustek.conf for
James> strip-height. Since it was said to be a value for how much
James> gets scanned at once and it said to remove it to have an
James> effective value of inifinity, I removed it. It did seem to
James> speed things up a little, but it still does a lot of
James> backtracking. Well anyways, I am running this on a 6x86 150+
James> with 32M and plenty of disk space. In any case, I think this
James> is way cool and I can't thank you all enough for making it
James> possible for me to stick this on my SCSI bus instead of using
James> that card that just takes up space.

The scanner has to backtrack each time a new SCSI "read data" command
is issued. The bigger the scan buffer, the fewer "read data" commands
are issued and the fewer backtracking you should see. The default
Linux kernel can handle a scan buffer up to 127.5KB and I find scan
speed quite acceptable with that buffer size.

I don't know what exactly the Windows driver does (in fact, I have
never actually seen the Windows driver working since it doesn't work
on my Alpha box...). I discussed the issue with a Mustek engineer a
long time ago and he said backtracking for the MFC-06000CZ is
unavoidable at high resolutions (probably because it has an internal
buffer of 128KB only). If you're saying that the windows driver does
not backtrack even at 600dpi in color mode, then this is obviously not
the whole truth. It might be that using a larger kernel buffer (say
1MB) might get rid of the backtracking completely, but it would at
least require some kernel hacking (also, I thought I read somewhere
that single SCSI transfers are limited to 128KB, am I
misremembering?).

Anyhow, I'd be interested in hearing the results if somebody wants to
dig deeper into this. I probably won't spend much time on it in the
near future as there are many other things to work on.

--david

--
Source code, list archive, and docs: http://www.azstarnet.com/~axplinux/sane/
To unsubscribe: mail -s unsubscribe sane-devel-request@listserv.azstarnet.com