[sane-devel] Need sane docs

Fri May 6 00:01:59 UTC 2016

On Thursday 05 May 2016 14:18:59 m. allan noah wrote:

> Xsane has no networking code in it. Everything you have described so
> far sounds like a problem in the brother4 backend. I suggest you try
> the same test using scanimage at the command line, and if it is still
> slow, compare to the windows driver. If you see a difference, ask
> Brother about brother4.
>
> allan
>
1st, there is not an intact windows install on the premises, I outlawed
it 15 years ago when I wiped an xp install on a lappy I had bought to
take with me when I was playing visiting fireman at other tv facilities
on a consultant basis, and installed what was then mandrake on it.

2nd, 'time scanimage -A' returns:
gene at coyote:/etc$ time scanimage -A
scanimage: rounded value of br-x from 297 to 296.973
scanimage: rounded value of br-y from 420 to 419.962

All options specific to device `net1;dev0':
  Mode:
    --mode Black & White|Gray[Error Diffusion]|True Gray|24bit Color[Fast] [24bit Color[Fast]]
        Select the scan mode
    --resolution 100|150|200|300|400|600|1200|2400|4800|9600dpi [200]
        Sets the resolution of the scanned image.
    --source FlatBed|Automatic Document Feeder(left aligned)|Automatic Document Feeder(left aligned,Duplex)|Automatic Document Feeder(centrally aligned)|
Automatic Document Feeder(centrally aligned,Duplex) [Automatic Document Feeder(left aligned)]
        Selects the scan source (such as a document-feeder).
    --brightness -50..50% (in steps of 1) [inactive]
        Controls the brightness of the acquired image.
    --contrast -50..50% (in steps of 1) [inactive]
        Controls the contrast of the acquired image.
  Geometry:
    -l 0..297mm (in steps of 0.0999908) [0]
        Top-left x position of scan area.
    -t 0..420mm (in steps of 0.0999908) [0]
        Top-left y position of scan area.
    -x 0..297mm (in steps of 0.0999908) [296.973]
        Width of scan-area.
    -y 0..420mm (in steps of 0.0999908) [419.962]
        Height of scan-area.

real	0m8.255s
user	0m0.008s
sys	0m0.004s

So that took 8 seconds and change.  Looks like you are correct, but
brother is very little help, btdt already. The email system will not let
me even get into the same building as anyone who knows something about
linux. To them the only diff is the package name extension, rpm or deb.

I just found that tcpdump thinks the first 5 transmissions from this
machine to the scanner have a bad checksum, as in:

root at coyote:/var/lib/apt# tcpdump -vv -i eth0 |grep scanner -
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
    coyote.coyote.den.54057 > scanner.coyote.den.54921: Flags [S], cksum 0x0f98 (incorrect -> 0x3511), seq 810478563, win 29200, options [mss 
1460,sackOK,TS val 41666836 ecr 0,nop,wscale 7], length 0
    scanner.coyote.den.54921 > coyote.coyote.den.54057: Flags [S.], cksum 0x03c4 (correct), seq 3617828754, ack 810478564, win 8688, options [mss 
1460,nop,wscale 0,nop,nop,sackOK,nop,nop,TS val 10020750 ecr 41666836], length 0
    coyote.coyote.den.54057 > scanner.coyote.den.54921: Flags [.], cksum 0x0f90 (incorrect -> 0x659a), seq 1, ack 1, win 229, options [nop,nop,TS val 
41666836 ecr 10020750], length 0
    scanner.coyote.den.54921 > coyote.coyote.den.54057: Flags [P.], cksum 0x5d53 (correct), seq 1:10, ack 1, win 8688, options [nop,nop,TS val 10021900 
ecr 41666836], length 9
    coyote.coyote.den.54057 > scanner.coyote.den.54921: Flags [.], cksum 0x0f90 (incorrect -> 0x5ff3), seq 1, ack 10, win 229, options [nop,nop,TS val 
41667124 ecr 10021900], length 0
    coyote.coyote.den.54057 > scanner.coyote.den.54921: Flags [P.], cksum 0x0f94 (incorrect -> 0x3900), seq 1:5, ack 10, win 229, options [nop,nop,TS val 
41667402 ecr 10021900], length 4
    scanner.coyote.den.54921 > coyote.coyote.den.54057: Flags [.], cksum 0x3a4e (correct), seq 10, ack 5, win 8684, options [nop,nop,TS val 10022800 ecr 
41667402], length 0
    scanner.coyote.den.54921 > coyote.coyote.den.54057: Flags [P.], cksum 0x06c2 (correct), seq 10:65, ack 5, win 8684, options [nop,nop,TS val 10023200 
ecr 41667402], length 55
    coyote.coyote.den.54057 > scanner.coyote.den.54921: Flags [.], cksum 0x0f90 (incorrect -> 0x592d), seq 5, ack 65, win 229, options [nop,nop,TS val 
41667499 ecr 10023200], length 0
    coyote.coyote.den.54057 > scanner.coyote.den.54921: Flags [F.], cksum 0x0f90 (incorrect -> 0x592c), seq 5, ack 65, win 229, options [nop,nop,TS val 
41667499 ecr 10023200], length 0
    scanner.coyote.den.54921 > coyote.coyote.den.54057: Flags [.], cksum 0x3826 (correct), seq 65, ack 6, win 8683, options [nop,nop,TS val 10023200 ecr 
41667499], length 0
    scanner.coyote.den.54921 > coyote.coyote.den.54057: Flags [FP.], cksum 0x381d (correct), seq 65, ack 6, win 8683, options [nop,nop,TS val 10023200 
ecr 41667499], length 0
    coyote.coyote.den.54057 > scanner.coyote.den.54921: Flags [.], cksum 0x592b (correct), seq 6, ack 66, win 229, options [nop,nop,TS val 41667499 ecr 
10023200], length 0
^C485 packets captured
485 packets received by filter
0 packets dropped by kernel

Which was collected by running yet another instance of "scanimage -A"

So, I am on the horn with brother, for about the last 2 hours.  Damn am
I glad LD to the lower 48 is in my monthly.  Anyway, they have opened
a thread, and I have copy/pasted what I have back to them. So we'll see
what develops from this.  I actually got somebody on the other end of
the wire who knew what linux actually was. I was snotty as hell wrapped
in flowers & home-spun comedy doing it though.

I'll post the gist of any usefull replies I get.

> On Thu, May 5, 2016 at 2:05 PM, Gene Heskett <gheskett at shentel.net> wrote:
> > On Thursday 05 May 2016 10:31:53 Richard Ryniker wrote:
> >> I doubt a gigabit Ethernet connection will make any significant
> >> difference.
> >
> > After investigating the lcd panels network settings for a wired lan,
> > and finding the best it can do is 100mbit-fd, that switch isn't
> > going to do a lot of good.  But the old one had a port that comes
> > and goes very intermittently, so I expect its been tapped by a local
> > lightnings EMP somewhere along the 6+ years its been in use here.
> >
> > I as I said before, can ping it in an average time of .3
> > milliseconds. But when xsane inits on the lan address, on launch
> > from a shell, the little "looking for scanners" box is drawn for
> > about 1 screen refresh and its wiped.  Then there is a 5 or 6 second
> > pause before xsane draws its windows.  Hooked up with a usb cable,
> > the opening screen draws are a small fraction of a second being
> > drawn.  And this is perceptually the exact same lag as the command
> > delay.

Thanks everybody, once again a suggestion from someone has resulted in
finding, but not yet in this case, fixing the problem.

GE used to call it progress, our most important product.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>