"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