kopia lustrzana https://gitlab.com/sane-project/website
85 wiersze
4.8 KiB
HTML
85 wiersze
4.8 KiB
HTML
|
<!-- received="Sat Sep 6 11:56:15 1997 MST" -->
|
||
|
<!-- sent="Sat, 6 Sep 1997 11:20:13 -0700" -->
|
||
|
<!-- name="David Mosberger-Tang" -->
|
||
|
<!-- email="David.Mosberger@acm.org" -->
|
||
|
<!-- subject="Re: SANE and Mustek MFC-600S" -->
|
||
|
<!-- id="199709061820.LAA00666@hopper.mosberger" -->
|
||
|
<!-- inreplyto="Pine.LNX.3.93.970829162117.3585A-100000@jklaas" -->
|
||
|
<title>sane-devel: Re: SANE and Mustek MFC-600S</title>
|
||
|
<h1>Re: SANE and Mustek MFC-600S</h1>
|
||
|
<b>David Mosberger-Tang</b> (<a href="mailto:David.Mosberger@acm.org"><i>David.Mosberger@acm.org</i></a>)<br>
|
||
|
<i>Sat, 6 Sep 1997 11:20:13 -0700</i>
|
||
|
<p>
|
||
|
<ul>
|
||
|
<li> <b>Messages sorted by:</b> <a href="date.html#136">[ date ]</a><a href="index.html#136">[ thread ]</a><a href="subject.html#136">[ subject ]</a><a href="author.html#136">[ author ]</a>
|
||
|
<!-- next="start" -->
|
||
|
<li> <b>Next message:</b> <a href="0137.html">David Mosberger-Tang: "Re: Backtracking in color scanning"</a>
|
||
|
<li> <b>Previous message:</b> <a href="0135.html">rwsimmon@ee.utah.edu: "support of Solaris x86?"</a>
|
||
|
<!-- nextthread="start" -->
|
||
|
<li> <b>Next in thread:</b> <a href="0142.html">Rogier Wolff: "Re: SANE and Mustek MFC-600S"</a>
|
||
|
<li> <b>Reply:</b> <a href="0142.html">Rogier Wolff: "Re: SANE and Mustek MFC-600S"</a>
|
||
|
<!-- reply="end" -->
|
||
|
</ul>
|
||
|
<!-- body="start" -->
|
||
|
<i>>>>>> On Fri, 29 Aug 1997 16:53:07 -0400 (EDT), jklaas <<a href="mailto:jklaas@ix.netcom.com">jklaas@ix.netcom.com</a>> said:</i><br>
|
||
|
<p>
|
||
|
James> I have a question about how sane goes about aquiring a scan<br>
|
||
|
James> from the Mustek single pass scanners. Why does it seem to do<br>
|
||
|
James> so much back tracking? When I scan in Windows no matter how<br>
|
||
|
James> high the resolution I set, it just goes in one single run.<br>
|
||
|
James> Where SANE seems to take a little bit at a time and then go<br>
|
||
|
James> back and do that plus a couple of pixels more. All the way<br>
|
||
|
James> up the end of the scan. It seems to take forever. Well, one<br>
|
||
|
James> of the options to set was in backend/mustek.conf for<br>
|
||
|
James> strip-height. Since it was said to be a value for how much<br>
|
||
|
James> gets scanned at once and it said to remove it to have an<br>
|
||
|
James> effective value of inifinity, I removed it. It did seem to<br>
|
||
|
James> speed things up a little, but it still does a lot of<br>
|
||
|
James> backtracking. Well anyways, I am running this on a 6x86 150+<br>
|
||
|
James> with 32M and plenty of disk space. In any case, I think this<br>
|
||
|
James> is way cool and I can't thank you all enough for making it<br>
|
||
|
James> possible for me to stick this on my SCSI bus instead of using<br>
|
||
|
James> that card that just takes up space.<br>
|
||
|
<p>
|
||
|
The scanner has to backtrack each time a new SCSI "read data" command<br>
|
||
|
is issued. The bigger the scan buffer, the fewer "read data" commands<br>
|
||
|
are issued and the fewer backtracking you should see. The default<br>
|
||
|
Linux kernel can handle a scan buffer up to 127.5KB and I find scan<br>
|
||
|
speed quite acceptable with that buffer size.<br>
|
||
|
<p>
|
||
|
I don't know what exactly the Windows driver does (in fact, I have<br>
|
||
|
never actually seen the Windows driver working since it doesn't work<br>
|
||
|
on my Alpha box...). I discussed the issue with a Mustek engineer a<br>
|
||
|
long time ago and he said backtracking for the MFC-06000CZ is<br>
|
||
|
unavoidable at high resolutions (probably because it has an internal<br>
|
||
|
buffer of 128KB only). If you're saying that the windows driver does<br>
|
||
|
not backtrack even at 600dpi in color mode, then this is obviously not<br>
|
||
|
the whole truth. It might be that using a larger kernel buffer (say<br>
|
||
|
1MB) might get rid of the backtracking completely, but it would at<br>
|
||
|
least require some kernel hacking (also, I thought I read somewhere<br>
|
||
|
that single SCSI transfers are limited to 128KB, am I<br>
|
||
|
misremembering?).<br>
|
||
|
<p>
|
||
|
Anyhow, I'd be interested in hearing the results if somebody wants to<br>
|
||
|
dig deeper into this. I probably won't spend much time on it in the<br>
|
||
|
near future as there are many other things to work on.<br>
|
||
|
<p>
|
||
|
--david<br>
|
||
|
<p>
|
||
|
<pre>
|
||
|
--
|
||
|
Source code, list archive, and docs: <a href="http://www.azstarnet.com/~axplinux/sane/">http://www.azstarnet.com/~axplinux/sane/</a>
|
||
|
To unsubscribe: mail -s unsubscribe <a href="mailto:sane-devel-request@listserv.azstarnet.com">sane-devel-request@listserv.azstarnet.com</a>
|
||
|
</pre>
|
||
|
<!-- body="end" -->
|
||
|
<p>
|
||
|
<ul>
|
||
|
<!-- next="start" -->
|
||
|
<li> <b>Next message:</b> <a href="0137.html">David Mosberger-Tang: "Re: Backtracking in color scanning"</a>
|
||
|
<li> <b>Previous message:</b> <a href="0135.html">rwsimmon@ee.utah.edu: "support of Solaris x86?"</a>
|
||
|
<!-- nextthread="start" -->
|
||
|
<li> <b>Next in thread:</b> <a href="0142.html">Rogier Wolff: "Re: SANE and Mustek MFC-600S"</a>
|
||
|
<li> <b>Reply:</b> <a href="0142.html">Rogier Wolff: "Re: SANE and Mustek MFC-600S"</a>
|
||
|
<!-- reply="end" -->
|
||
|
</ul>
|