Re: Problems with Acer ScanPrisa 640S

From: Sebastien Sable (sebastien.sable@gmx.net)
Date: Sat Oct 21 2000 - 08:12:17 PDT

  • Next message: Peter Kirchgessner: "Re: Patches for sanei_debug.h/sanei_init_debug.c and the HP-backend"

    "Lawrence Glaister" <lg@jfm.bc.ca> writes:

    > 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.

    My scanner is probably very slow compared to others (it's 4 years
    old). But even with this slow scanner, I can always put
    expected_read_bytes to its maximum value without any problem. So the
    speed test is probably useless (at least up to 300dpi with scsi
    scanners).

    > 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.

    My scanner was only blocking during the real scan with a picture of
    more than about 400KB. I am going to try to describe it more
    precisely:

    when the scan starts, the first value of expected_read_bytes just
    before scsi_read in SCSISource_get is the maximum value (~32000 or
    something).
    Then nearly each time a new scsi_read happens expected_read_bytes is
    decreased of about 2000. This reduction happens in the calculation of:
       ps->pss->expected_read_bytes =
               ((int) (msecs/ps->pss->ms_per_line))*ps->pss->bytes_per_line;

    So while scanning, you have the number of bytes read at each step:
    step1: 32000
    step2: 30000
    step3: 28000
    ...
    step15: 4000
    step16: 2000
    step18: 0
    step19: 0
    ...

    Of course, if you arrive at step 18, you ask for nothing, so you get
    nothing and the scan just starts an infinite loop asking nothing to
    the scanner... eheh -> problem

    This happens if your picture is bigger than :
    (32000 + 30000 + 28000 + .... + 4000 + 2000) = ~400KB

    (my old math teachers would kill me for such a line! I said it was
    _about_ 32000)

    If I force expected_read_bytes to be always the maximum value, the
    scanner works perfectly.

    > 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).

    I tried your patches when you suggested them. They didn't change
    anything with my scanner (and didn't appear in the debug info). I
    think that those problems (-ve in RGBRouter_remaining and EAGAIN)
    never happen in my case (it is probably USB specific?).

    Indeed I just tried a 24.8MB picture (full A4 with 300dpi color) and
    everything worked fine.

    A+

    -- 
    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



    This archive was generated by hypermail 2b29 : Sat Oct 21 2000 - 08:06:16 PDT