Hi, I just looked curiously on the data and I think there are some similarities between the scsi based scanners driven by the microtek2 backend and the 5600:
command 0x24 is used to setup the scan window, probably first a fixed window for calibration and second the actual scan window. command 0x28 0xnn 0x80 reads image information (width, height, bytes) command 0x28 0xnn 0x81 reads system status (Lamps on/off, buttons,) and 0x2a 0xnn 0x81 should set the status. command 0x28 0xnn 0x82 reads scanner attributes (resolution, width, heigt of the scan area.......) Maybe a look at the microtek2 sources helps you. I also have some (quite old) documentation but it may help. Tell me if I shall send it to you (its an ugly MS Word file :-() Regards, Karsten On Wednesday 15 September 2004 21:57, Susheel Yadav wrote: > Thanks a lot Bertrik for your analysis. I have figured > out some things - I have written those down in the > last link on the web page. > > *request=0x24 value=0x00 data=0x45 bytes > The data transferred in this request did not change > even if I moved the scan area horizontally keeping the > size constant. This makes me think that maybe it scans > the whole row and the software clips the image later. > What do you think? > > *request=0x26 value=0x00 data=0xef00 bytes > This happens before bulk transfers, and the data > returned in Nth step is sent to the scanner in the > (N+1)th request. > > *The bulk transfer is followed by a small transfer of > 0x40 bytes. This returns 0x10 bytes. The last 0x30 > bytes sent always remain same, and the first 0x10 > bytes are the ones that were returned from the > previous cycle. Could this signify the position of the > next chunk of data? > > *request=0x28, 0x40, 0x83, 0x12 repeat and I think > they are status check. The windows driver has a > scanner detector utility which when turned on, keeps > sending those packets. > > *request=0x28 value=0x83 > This request gets the data that is send back in some > 0x40 0x2a 0x81 requests. > > *request=0x29 seems to denote the end of transfer > since there is no more bulk data after that. > > --- Bertrik Sikken <[email protected]> wrote: > > Susheel Yadav wrote: > > > Hi, > > > I am trying to write the linux driver for Microtek > > > Scanmaker 5600 scanner. I used USBSnoopy to > > > > generate > > > > > these logs from VMWare/Win2k. I have filtered out > > > > the > > > > > big bulk transfers. The log files are still in > > > > ~200KB > > > > > range. I am providing a link below with the log > > > > files. > > > > > I have made some progress in identifying the > > > > status > > > > > check packets, and some pattern in the bulk > > > > transfers, > > > > > but I have no idea what those medium sized control > > > packets mean. I would appreciate any help. > > > > > > http://blanca.homelinux.com/usblogs/ > > > > > > Thank you very much! > > > > What medium sized control packets do you mean? > > > > > > I looked a bit at the logs and noticed 10 unique > > patterns: > > > > * request=0x12, value=0x00: read version info? > > The data returned by this transfer contains the > > strings > > "ScanMaker 5600 1.30" > > "NowV0.10NewV0.10" > > > > * request=0x24, value=0x00: write 0x45 bytes of scan > > settings? > > This transfer contains numbers like 1200, 600, 300, > > which are likely > > DPI or LPI resolutions. I think that scan area is > > also coded in this > > transfer. It noticed this transfer happens twice > > (once for calibration, > > then once for the actual scan?) > > > > * request=0x26, value=0x00: prepare bulk read (index > > = length) > > This transfer always seems to happen just before a > > bulk read > > > > * request=0x28, value=0x80: get a bunch of bytes > > (don't know what) > > > > * request=0x28, value=0x81: read some 9-byte buffer > > > > * request=0x28, value=0x82: read scan capabilities? > > This transfer also has typical DPI numbers, but > > always seem to be > > the same (not always same length though) > > > > * request=0x28, value=0x83: read status byte? > > (00 = ready, 08 = not ready?) > > > > * request=0x29, value=0x2101: prepare bulk write > > (index=length=20400) > > Not sure yet what is written here, looks like 16-bit > > data. > > Could be calibration data. > > > > * request=0x2A, value=0x81: write some 9-byte buffer > > Same buffer as read by request=0x28,value=0x81 > > > > * request=0x40, value=0x00: read scanner status > > This transfer seems to happen after about any other > > transfer. > > > > > > I think a good transfer to concentrate on is the one > > with request=0x24. > > This one seems to indicate scan settings, so try out > > some different > > scan area's, resolutions, etc. and see if you can > > spot any log changes > > in this transfer that match with your settings. > > The stuff written to the scanner using the transfer > > with request=0x29 > > could be calibration data. I think that in initial > > tests you can get > > away with just writing some constant data like 0xFF. > > > > Hope this helps (and that I'm not telling you > > anything you knew > > already) > > > > Bertrik > > > > > > > > > > > > -- > > sane-devel mailing list: > > [email protected] > > http://lists.alioth.debian.org/mailman/listinfo/sane-devel > > > Unsubscribe: Send mail with subject "unsubscribe > > your_password" > > to > > [email protected] > > __________________________________ > Do you Yahoo!? > Take Yahoo! Mail with you! Get it on your mobile phone. > http://mobile.yahoo.com/maildemo
