<br><br><div class="gmail_quote">On Thu, Aug 16, 2012 at 9:05 PM, m. allan noah <span dir="ltr"><<a href="mailto:kitno455@gmail.com" target="_blank">kitno455@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Wireshark makes things a little more difficult, because it shows all <br></blockquote><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">the low level USB stuff, that really does not matter to us. So, you<br>

have to learn to ignore every other packet in those logs, and the<br>
first 0x40 bytes of the packets you do care about.<br></blockquote><div>I'm always startled by the overhead and the layers of indirection involved in modern protocols.<br> <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

I took a brief spin thru your logs, and it appears that the scanner is<br>
unhappy when we send the 0xd6 command, which I call SET_SCAN_MODE.<br></blockquote><div>I tried a simple hack of removing all calls to ssm_do, ssm_buffer and ssm_cmd.  I was able to get a scan out of the scanner!  However, it came out at 600 DPI.<br>
 </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Then we make a series of small
area, low resolution scans in the working driver, changing one<br>
parameter each time. Then we see how the calls to the 0xe5 command<br>
change. It might be that we never determine what they do, or that they<br>
only do something under the windows driver.<br></blockquote><div>FYI : I have a Linux driver from Canon.  It consists of a wrapper around a binary blob.  This wrapper appears to talk the sane net protocol with the binary blob.  It also uses a SUID root program to talk with the USB device.<br>
<br></div>I've done a first batch of tests with --mode --resolution and --UltrasonicDoubleFeedDetect params.  Unfortunately the binary driver seems to ignore -x, -y and complains if I use any --Size except A4.  Output, along with my test script is here: <br>
    <a href="http://pied.nu/Sane/canon_dr-20120816-1029.tar.gz">http://pied.nu/Sane/canon_dr-20120816-1029.tar.gz</a><br><br>-Philip<br></div>