Re: Problems with Acer ScanPrisa 640S

From: Lawrence Glaister (lg@jfm.bc.ca)
Date: Fri Oct 20 2000 - 20:08:52 PDT

  • Next message: Oliver Rauch: "Re: make dll.c robust against it being listed in its configuration file..."

    Greetings Sebastien
    You have hit on one of the symptoms I noticed as well... due to the
    RGBRouter code, the scsi speed test gets hosed especially on higher
    resolution scans. I am wondering if the speed test can be removed.... what
    does it really get used for? Since there is probably only a 3-1 range in
    times between the slowest and fastest scanners, does the rate really need to
    be measured... it doesn't seem to get used for setting timeouts.
    Do you notice your scanner blocking during the speed test or during a real
    scan? I found a "hang condition" was occurring during the speed test because
    RGBRouter was called with a small 32k buffer to test the transfer rate with.
    The rest of the code was expecting a 23mb image to be scanned and the
    RGBRouter_remaining() function broke with -ve return values.
    The second problem I noticed was the EAGAIN problem with the USB driver.
    Somewhere in the 2.4.0 code, the USB drivers stopped blocking on a read and
    started returning EAGAIN and 0 bytes when the scanner was busy (noticeable
    during scanhead backtracking).
    =======================================================
    Lawrence Glaister VE7IT email: lg@jfm.bc.ca
    1462 Madrona Drive http://jfm.bc.ca
    Nanoose Bay BC Canada
    V9P 9C9
    =======================================================
    ----- Original Message -----
    From: Sebastien Sable <sebastien.sable@gmx.net>
    To: <sane-devel@mostang.com>
    Sent: Friday, October 20, 2000 5:53 PM
    Subject: Re: Problems with Acer ScanPrisa 640S

    > Steve Underwood <steveu@coppice.org> writes:
    >
    > > I updated the backend to merge the colours properly in May. Since then I
    have had
    > > little feedback. Lawrence is the first person to fully work through
    anything from
    > > "I have a problem" to "I have a cure" since then. People need some
    serious coaxing
    >
    > This time I think "I have a cure" ;)
    >
    > I found that ps->pss->expected_read_bytes calculated in SCSISource_get
    > was slowly decreasing down to 0. At this point
    > (ps->pss->expected_read_bytes == 0) the scanner would block.
    >
    > To solve this, I can put it to an arbitrary high value.
    >
    > // ps->pss->expected_read_bytes =
    > // ((int)
    (msecs/ps->pss->ms_per_line))*ps->pss->bytes_per_line;
    >
    > ps->pss->expected_read_bytes = 50000;
    >
    > then this line later
    > ps->pss->expected_read_bytes = MIN(ps->pss->expected_read_bytes,
    > (size_t) ps->absolute_max);
    > put it to absolute_max.
    >
    > In this case, my scanner works fine and does not block anymore. Of
    > course, it's a dirty trick.
    > May be the ms_per_line reported by the scanner is not right or
    > something?
    >
    > --
    > Sébastien Sablé
    > sebastien.sable@gmx.net
    >
    > --
    > Source code, list archive, and docs: http://www.mostang.com/sane/
    > To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
    >

    --
    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 : Fri Oct 20 2000 - 20:00:46 PDT