kopia lustrzana https://gitlab.com/sane-project/website
218 wiersze
8.5 KiB
HTML
218 wiersze
8.5 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
|
|
"http://www.w3.org/TR/REC-html40/loose.dtd">
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>sane-devel: Re: [snapscan] More USB updates</TITLE>
|
|
<META NAME="Author" CONTENT="Steve Underwood (steveu@coppice.org)">
|
|
<META NAME="Subject" CONTENT="Re: [snapscan] More USB updates">
|
|
</HEAD>
|
|
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
|
|
<H1>Re: [snapscan] More USB updates</H1>
|
|
<!-- received="Sun Nov 19 17:43:34 2000" -->
|
|
<!-- isoreceived="20001120014334" -->
|
|
<!-- sent="Mon, 20 Nov 2000 09:58:15 +0800" -->
|
|
<!-- isosent="20001120015815" -->
|
|
<!-- name="Steve Underwood" -->
|
|
<!-- email="steveu@coppice.org" -->
|
|
<!-- subject="Re: [snapscan] More USB updates" -->
|
|
<!-- id="3A188537.E3FCBA42@coppice.org" -->
|
|
<!-- inreplyto="Springmail.105.974682979.0.26662100@www.springmail.com" -->
|
|
<STRONG>From:</STRONG> Steve Underwood (<A HREF="mailto:steveu@coppice.org?Subject=Re:%20[snapscan]%20More%20USB%20updates&In-Reply-To=<3A188537.E3FCBA42@coppice.org>"><EM>steveu@coppice.org</EM></A>)<BR>
|
|
<STRONG>Date:</STRONG> Sun Nov 19 2000 - 17:58:15 PST
|
|
<P>
|
|
<!-- next="start" -->
|
|
<LI><STRONG>Next message:</STRONG> <A HREF="0273.html">cbagwell@sprynet.com: "Re: Re: [snapscan] More USB updates"</A>
|
|
<UL>
|
|
<LI><STRONG>Previous message:</STRONG> <A HREF="0271.html">cbagwell@sprynet.com: "[snapscan] More USB updates"</A>
|
|
<LI><STRONG>In reply to:</STRONG> <A HREF="0271.html">cbagwell@sprynet.com: "[snapscan] More USB updates"</A>
|
|
<!-- nextthread="start" -->
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0273.html">cbagwell@sprynet.com: "Re: Re: [snapscan] More USB updates"</A>
|
|
<LI><STRONG>Reply:</STRONG> <A HREF="0273.html">cbagwell@sprynet.com: "Re: Re: [snapscan] More USB updates"</A>
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#272">[ date ]</A>
|
|
<A HREF="index.html#272">[ thread ]</A>
|
|
<A HREF="subject.html#272">[ subject ]</A>
|
|
<A HREF="author.html#272">[ author ]</A>
|
|
</UL>
|
|
<HR NOSHADE><P>
|
|
<!-- body="start" -->
|
|
<P>
|
|
<A HREF="mailto:cbagwell@sprynet.com?Subject=Re:%20[snapscan]%20More%20USB%20updates&In-Reply-To=<3A188537.E3FCBA42@coppice.org>">cbagwell@sprynet.com</A> wrote:
|
|
<BR>
|
|
<P><EM>> I've committed to snapscan's CVS server a few changes needed to get
|
|
</EM><BR>
|
|
<EM>> USB working on my Acer 640BU scanner. There are only two changes.
|
|
</EM><BR>
|
|
<EM>> The first is so that usb read()'s will retry if it ever returns
|
|
</EM><BR>
|
|
<EM>> EAGAIN.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> The second is a fix for the problem as first described by
|
|
</EM><BR>
|
|
<EM>> Lawrence Glaister. There is a case upon initial startup of
|
|
</EM><BR>
|
|
<EM>> the scan that RGBRouter_remaining() could return a negative value
|
|
</EM><BR>
|
|
<EM>> which would in turn cause the rest of the code to go into an
|
|
</EM><BR>
|
|
<EM>> infinite loop. This seems to only happen for me at 600 dpi
|
|
</EM><BR>
|
|
<EM>> but it seems like it should happen in all cases.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> Would a few people please code review my changes to snapscan_sources.c:RGBRouter_remaining() and verify the bad effects
|
|
</EM><BR>
|
|
<EM>> that could happen if cb_start == -1. The main thing that was
|
|
</EM><BR>
|
|
<EM>> happening was that it caused the code to subtract cb_size from
|
|
</EM><BR>
|
|
<EM>> the current remaining buffer length. Since your never going to
|
|
</EM><BR>
|
|
<EM>> have more data then the cb_size, it was always negative.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> Perhaps I'm missing what the original purpose of that code was
|
|
</EM><BR>
|
|
<EM>> meant to do.
|
|
</EM><BR>
|
|
<P>Lawrence was a bit confused about the purpose of this code, too. Here is a copy of an off list explanation I sent
|
|
<BR>
|
|
him..........
|
|
<BR>
|
|
<P>Hi Lawrence,
|
|
<BR>
|
|
<P>There is a limitation in the work I did, that if you try to scan a Y line
|
|
<BR>
|
|
image you will actually get Y - b lines of scan, where b is the number of
|
|
<BR>
|
|
lines absorbed by the circular buffering process. It shouldn't really work
|
|
<BR>
|
|
this way. The size of the scan should be bumped up by the number of lines
|
|
<BR>
|
|
needed for the circular buffering. I didn't delve deeply enough to sort out
|
|
<BR>
|
|
how to achieve this cleanly. One consequence is that a scan can be so small
|
|
<BR>
|
|
that after the circular buffering it is less than zero in length! Getting the
|
|
<BR>
|
|
total scanned image size right is not quite the trivial matter is sounds like.
|
|
<BR>
|
|
When you find the scan area limits you haven't yet found the amount which
|
|
<BR>
|
|
needs to be subtracted to compensate for the circular buffering. If you don't,
|
|
<BR>
|
|
then trying to scan a complete page might try to scan an area greater than the
|
|
<BR>
|
|
scanner actually can. Now it may be that the scanner allows for this, and
|
|
<BR>
|
|
reports a maximum area a little less than the real maximum. This would be
|
|
<BR>
|
|
sensible, but then many designs are not! Not knowing quite what happens, and
|
|
<BR>
|
|
whether all the covered scanner models might follow the same rules, I made the
|
|
<BR>
|
|
code the way it is now.
|
|
<BR>
|
|
<P>Anyway, that's not your problem here, as the scan you are attempting is large.
|
|
<BR>
|
|
<P>SANE_Int remaining1 =
|
|
<BR>
|
|
(TxSource_remaining (pself) - ps->cb_size + ps->cb_line_size);
|
|
<BR>
|
|
<P>If cb_start is -1 when RGBRouter_remaining is called the scan hasn't yet
|
|
<BR>
|
|
filled the circular buffer, and so has not yet output any data. I think this
|
|
<BR>
|
|
should only occur when the circular buffer is totally empty. At this point the
|
|
<BR>
|
|
remaining bytes which would be expected to be output are:
|
|
<BR>
|
|
<P> The bit still not loaded from the scanner -> TxSource_remaining (pself)
|
|
<BR>
|
|
less the amount need to fill the circular buffer, and bring it to the
|
|
<BR>
|
|
point of outputting something -> (ps->cb_line_size - ps->pos)
|
|
<BR>
|
|
<P>The above code should be OK, if my assumption is right. If
|
|
<BR>
|
|
TxSource_remaining() is less than one scan line less than the size of the
|
|
<BR>
|
|
circular buffer there will be major trouble! As I said above, a tiny scan
|
|
<BR>
|
|
could currently cause this, but I don't see how it would happen for any larger
|
|
<BR>
|
|
scan, unless something else goes wrong.
|
|
<BR>
|
|
<P><P>SANE_Int remaining2 =
|
|
<BR>
|
|
(TxSource_remaining (pself) + ps->cb_line_size - ps->pos);
|
|
<BR>
|
|
<P>If cb_start is not -1 when RGBRouter_remaining is called the scan has got past
|
|
<BR>
|
|
the initial filling of the buffer, and into some real outputting. At this
|
|
<BR>
|
|
point the remaining bytes which would be expected to be output are:
|
|
<BR>
|
|
<P> The bit still not loaded from the scanner -> TxSource_remaining (pself)
|
|
<BR>
|
|
plus the bit thats still in the circular buffer -> (ps->cb_line_size -
|
|
<BR>
|
|
ps->pos)
|
|
<BR>
|
|
<P>The above code looks OK to me, and I think it should cover all circumstances.
|
|
<BR>
|
|
<P><P>The question you need to answer is how does:
|
|
<BR>
|
|
<P>[snapscan] inquiry: expected total scan data: 25158951 bytes
|
|
<BR>
|
|
<P>lead to:
|
|
<BR>
|
|
<P>[snapscan] TxSource_remaining =30592
|
|
<BR>
|
|
<P>when the scan is only just starting. It looks like the software has seriously
|
|
<BR>
|
|
run out of fingers to count with!
|
|
<BR>
|
|
<P>Regards,
|
|
<BR>
|
|
Steve
|
|
<BR>
|
|
<P><P><PRE>
|
|
--
|
|
Source code, list archive, and docs: <A HREF="http://www.mostang.com/sane/">http://www.mostang.com/sane/</A>
|
|
To unsubscribe: echo unsubscribe sane-devel | mail <A HREF="mailto:majordomo@mostang.com?Subject=Re:%20[snapscan]%20More%20USB%20updates&In-Reply-To=<3A188537.E3FCBA42@coppice.org>">majordomo@mostang.com</A>
|
|
</PRE>
|
|
<P><!-- body="end" -->
|
|
<HR NOSHADE>
|
|
<UL>
|
|
<!-- next="start" -->
|
|
<LI><STRONG>Next message:</STRONG> <A HREF="0273.html">cbagwell@sprynet.com: "Re: Re: [snapscan] More USB updates"</A>
|
|
<LI><STRONG>Previous message:</STRONG> <A HREF="0271.html">cbagwell@sprynet.com: "[snapscan] More USB updates"</A>
|
|
<LI><STRONG>In reply to:</STRONG> <A HREF="0271.html">cbagwell@sprynet.com: "[snapscan] More USB updates"</A>
|
|
<!-- nextthread="start" -->
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0273.html">cbagwell@sprynet.com: "Re: Re: [snapscan] More USB updates"</A>
|
|
<LI><STRONG>Reply:</STRONG> <A HREF="0273.html">cbagwell@sprynet.com: "Re: Re: [snapscan] More USB updates"</A>
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#272">[ date ]</A>
|
|
<A HREF="index.html#272">[ thread ]</A>
|
|
<A HREF="subject.html#272">[ subject ]</A>
|
|
<A HREF="author.html#272">[ author ]</A>
|
|
</UL>
|
|
<!-- trailer="footer" -->
|
|
<HR NOSHADE>
|
|
<P>
|
|
<SMALL>
|
|
<EM>
|
|
This archive was generated by <A HREF="http://www.hypermail.org/">hypermail 2b29</A>
|
|
: <EM>Sun Nov 19 2000 - 17:44:40 PST</EM>
|
|
</EM>
|
|
</SMALL>
|
|
</BODY>
|
|
</HTML>
|