Hi, Indeed, the commands are identical as far as I can tell, except for a difference how some of the SCSI command bytes are mapped to the USB request, value and index fields and some commands that are sent just before a bulk transfer is done.
I think it's worth linking to this thread from the scanner search engine page for this scanner. Regards, Bertrik Karsten Festag wrote: > 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 <bert...@zonnet.nl> 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
