Mbosowo I Sampson wrote: > > > On Sun, 5 Sep 2004, Bertrik Sikken wrote: > >> Mbosowo I Sampson wrote: >> >>> I'm interested in writing a back end for the 3970. I've been reading >>> specs, looking at other back ends, trying to get familiar with sane, >>> etc... Its all a little daunting. I feel as though I know more than I >>> did a few days ago, but not nearly enough to even begin to know where >>> to start. I think what I'm looking for here is a general overview of >>> how sane interacts with a USB scanner. I feel like I can't see the >>> forest because I'm preoccupied with studying the composition of bark >>> on each tree. Once I have the conceptual part down, I think all the >>> details will fall into place as I continue reading the documentation. >>> >>> What I'm asking for is a break down of the steps involved for a scan >>> to be made. I'm trying to conceptualize how libusb, the driver I will >>> write, the front end, and the chip set all interact together to >>> execute a successful scan. Doesn't have to be in minute detail, but >>> some detail is always good. >> >> >> I can tell you a little about how the niash backend was developed. >> This may not be the best example, but the process worked quite well >> in the end. > > [snip] > > > > > So did you have to reverse engineer the protocol when you wrote the > back end? I think I have a handle on what's required to write a sane > back end . My issue now is reverse engineering the protocol. After > reading your post I got all fired up to write a stand alone app to try > turning on the lamp, until I realized I have no idea *how* to turn on > the lamp. don't know what registers to write, what values they require, > etc... That's my next hurdle.
Yes, I did have to reverse engineer the scanner's internals entirely. The protocol how to read/write a scanner register was figured out quite quickly. The hard part was figuring out what each register did (the niash type scanners have about 40 registers) and we never managed to find it out for some registers. The thing to do next is getting lots of USB logs from the windows driver, each one capturing a simple as possible event or change in parameters. This allows you to compare the logs and look for differences between logs. For example: * plugging in the scanner * turning light on/off (if the windows UI allows it) * doing a preview scan * scanning a tiny area in various positions (to figure out how the position of the scan area is encoded in the data sent to the scanner) * scanning a tiny area and a bigger area (to figure out how the size of the scan area is encoded) * scanning at various resolutions * etc. In some cases, the windows driver may be fooling you. For example, scanning in greyscale or B/W may be implemented by doing a scan in color and making it greyscale or B/W in software. Or perhaps the resolution is interpolated from a lower resolution. I think there's a lot of experience on this list in interpreting logs and knowledge about the internals of scanners, so just ask if you get stuck (better yet, ask _before_ you get stuck : )). Try to use the usbsnoopy/sniffusb version that outputs plain text. There are even some perl-scripts already that can parse and simplify text-based logs. Good luck, Bertrik
