Re: [snapscan] More USB updates

From: Steve Underwood (steveu@coppice.org)
Date: Sun Nov 19 2000 - 17:58:15 PST

  • Next message: cbagwell@sprynet.com: "Re: Re: [snapscan] More USB updates"

    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