cbagwell@sprynet.com wrote:
> I've committed to snapscan's CVS server a few changes needed to get
> USB working on my Acer 640BU scanner. There are only two changes.
> The first is so that usb read()'s will retry if it ever returns
> EAGAIN.
>
> The second is a fix for the problem as first described by
> Lawrence Glaister. There is a case upon initial startup of
> the scan that RGBRouter_remaining() could return a negative value
> which would in turn cause the rest of the code to go into an
> infinite loop. This seems to only happen for me at 600 dpi
> but it seems like it should happen in all cases.
>
> Would a few people please code review my changes to snapscan_sources.c:RGBRouter_remaining() and verify the bad effects
> that could happen if cb_start == -1. The main thing that was
> happening was that it caused the code to subtract cb_size from
> the current remaining buffer length. Since your never going to
> have more data then the cb_size, it was always negative.
>
> Perhaps I'm missing what the original purpose of that code was
> meant to do.
Lawrence was a bit confused about the purpose of this code, too. Here is a copy of an off list explanation I sent
him..........
Hi Lawrence,
There is a limitation in the work I did, that if you try to scan a Y line
image you will actually get Y - b lines of scan, where b is the number of
lines absorbed by the circular buffering process. It shouldn't really work
this way. The size of the scan should be bumped up by the number of lines
needed for the circular buffering. I didn't delve deeply enough to sort out
how to achieve this cleanly. One consequence is that a scan can be so small
that after the circular buffering it is less than zero in length! Getting the
total scanned image size right is not quite the trivial matter is sounds like.
When you find the scan area limits you haven't yet found the amount which
needs to be subtracted to compensate for the circular buffering. If you don't,
then trying to scan a complete page might try to scan an area greater than the
scanner actually can. Now it may be that the scanner allows for this, and
reports a maximum area a little less than the real maximum. This would be
sensible, but then many designs are not! Not knowing quite what happens, and
whether all the covered scanner models might follow the same rules, I made the
code the way it is now.
Anyway, that's not your problem here, as the scan you are attempting is large.
SANE_Int remaining1 =
(TxSource_remaining (pself) - ps->cb_size + ps->cb_line_size);
If cb_start is -1 when RGBRouter_remaining is called the scan hasn't yet
filled the circular buffer, and so has not yet output any data. I think this
should only occur when the circular buffer is totally empty. At this point the
remaining bytes which would be expected to be output are:
The bit still not loaded from the scanner -> TxSource_remaining (pself)
less the amount need to fill the circular buffer, and bring it to the
point of outputting something -> (ps->cb_line_size - ps->pos)
The above code should be OK, if my assumption is right. If
TxSource_remaining() is less than one scan line less than the size of the
circular buffer there will be major trouble! As I said above, a tiny scan
could currently cause this, but I don't see how it would happen for any larger
scan, unless something else goes wrong.
SANE_Int remaining2 =
(TxSource_remaining (pself) + ps->cb_line_size - ps->pos);
If cb_start is not -1 when RGBRouter_remaining is called the scan has got past
the initial filling of the buffer, and into some real outputting. At this
point the remaining bytes which would be expected to be output are:
The bit still not loaded from the scanner -> TxSource_remaining (pself)
plus the bit thats still in the circular buffer -> (ps->cb_line_size -
ps->pos)
The above code looks OK to me, and I think it should cover all circumstances.
The question you need to answer is how does:
[snapscan] inquiry: expected total scan data: 25158951 bytes
lead to:
[snapscan] TxSource_remaining =30592
when the scan is only just starting. It looks like the software has seriously
run out of fingers to count with!
Regards,
Steve
-- 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 : Sun Nov 19 2000 - 17:44:40 PST