[sane-devel] backend coding overview

[Bertrik Sikken]

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