Alex Eftimie, Thanks. I'm not usb protocol expert, so as far as I can see on the first run usbmon output it like this:
eead2240 1101775494 S Bo:3:003:3 -115 4 = 1ba81200 eead2240 1101775516 C Bo:3:003:3 0 4 > eead2240 1101775554 S Bi:3:003:4 -115 1024 < eead2240 1101776007 C Bi:3:003:4 -121 70 = a8004310 5865726f 78202020 5865726f 7820576f 726b4365 6e747265 20333232 "1ba81200" is INQUIRY command to the scanner, and scanner replies valid packet. On the second run in the same place: ec424e40 1120416714 S Bo:3:003:3 -115 4 = 1ba81200 ec424e40 1120416733 C Bo:3:003:3 0 4 > eeef3600 1120416783 S Bi:3:003:4 -115 1024 < eeef3600 1121416871 C Bi:3:003:4 -2 0 Driver sends INQUIRY as before, but device reply 0. In smfp logs I see that communication with 3:005:3 and 3:005:4 endpoints is exactly the same, and device reply 0 on the second request. But they also have communiction with 3:005:2 and 3:005:1 endpoints which reply valid data each time: ebbe6480 1337401585 S Bi:3:005:2 -115 1024 < ebbe6480 1337401910 C Bi:3:005:2 -2 0 ee630780 1337403079 S Bi:3:005:2 -115 1024 < ee630540 1337403122 S Bo:3:005:1 -115 4 = 1ba81200 ee630540 1337403153 C Bo:3:005:1 0 4 > ee630780 1337403606 C Bi:3:005:2 0 70 = a8004310 5865726f 78202020 5865726f 7820576f 726b4365 6e747265 20333232 ebbe66c0 1337503267 S Bi:3:005:2 -115 1024 < ebbe66c0 1337503358 C Bi:3:005:2 -2 0 ebe2b480 1337767156 S Bo:3:005:3 -115 4 = 1ba81200 ebe2b480 1337767178 C Bo:3:005:3 0 4 > ebe2b480 1337767213 S Bi:3:005:4 -115 1024 < ebe2b480 1337767626 C Bi:3:005:4 -121 70 = a8004310 5865726f 78202020 5865726f 7820576f 726b4365 6e747265 20333232 Second run: ef9b6780 1364024034 S Bi:3:005:2 -115 1024 < ef9b6780 1364024332 C Bi:3:005:2 -2 0 f6809480 1364025511 S Bi:3:005:2 -115 1024 < f68093c0 1364025549 S Bo:3:005:1 -115 4 = 1ba81200 f68093c0 1364025593 C Bo:3:005:1 0 4 > f6809480 1364026031 C Bi:3:005:2 0 70 = a8004310 5865726f 78202020 5865726f 7820576f 726b4365 6e747265 20333232 ee572c00 1364125725 S Bi:3:005:2 -115 1024 < ee572c00 1364125809 C Bi:3:005:2 -2 0 efb4e9c0 1364403169 S Bo:3:005:3 -115 4 = 1ba81200 efb4e9c0 1364403198 C Bo:3:005:3 0 4 > efb4e9c0 1364403229 S Bi:3:005:4 -115 1024 < efb4e9c0 1365403290 C Bi:3:005:4 -2 0 And then driver work only with 3:005:1/3:005:2 endpoints. There was also some communication with printer (3:005:0) which I skipped. It seems like sanei seeing only one device at 3:005:3/3:005:4 (and that target fails), but smfp sees two, and first one (at 3:005:1/3:005:2) is actually working correctly. Need help of some usb expert at this point. -abc On Mon, Jul 22, 2013 at 10:33:58PM +0200, Alex Eftimie wrote: > On Mon, Jul 8, 2013 at 10:39 AM, ABC <abc at telekom.ru> wrote: > > Alex Eftimie, > > > > On Sun, Jun 30, 2013 at 01:56:08PM +0300, Alex Eftimie wrote: > >> On Sun, Jun 30, 2013 at 1:31 PM, ABC <abc at telekom.ru> wrote: > >> > It maybe be becasue (it is possible) that smfp using different scanning > >> > mode, like different resolution. (And then doing some image conversion > >> > internally.) xerox_mfp driver's settings are 'physical' for the device. > >> > >> Well, I'm setting the resolution myself, with --resolution=300 (the > >> same for xerox_mfp and smfp). Also, I'm using as color mode: "Lineart" > >> for xerox_mfp and "Black and White - Line Art" for smfp. But still 4 > >> seconds vs 10 seconds. Can I get 'physical' with smfp :D? > > > > Regarding longer scans via smfp driver, I looked your usbmon logs. Scan > > parameters seems to be nearly equal. And I see that smfp (1.mon.out) > > driver send device INQUIRY reqest 4 times with interval from first to last > > request ~3 seconds. Total time of smfp scan is 8.7 seconds. Total time > > of xerox_mfp scan is 4.3 seconds. Image data reading time in both cases > > is nearly 1 second. Time between first image request and image data flow > > is ~3.5 seconds. So I conclude that smfp driver spend difference in > > time internally and actual speed of working with device and device > > itself is the same. Why is smfp driver spending time inernally? > > Unknown. It may be just some hardcoded intervals between commands. > > Sorry for the late reply. > > > It seems your usbmon logs don't contain case when scanimage fail with > > xerox_mfp driver. As I understand it would fail if `scanimage -L' will > > be run twice (it will fail second time). So it will be useful to have > > usbmon log of such case. > > Here: https://www.dropbox.com/sh/u4p87ustkef1dw5/12nemzRUYO are the > usbmon logs for: default (xerox_mfp) and proprietari (smfp) drivers, > running two consecutive `scanimage -L`. > > > Hope this will give you some hints regarding the underlying issue. > > Cheers, > Alex > > -- > sane-devel mailing list: sane-devel at lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel > Unsubscribe: Send mail with subject "unsubscribe your_password" > to sane-devel-request at lists.alioth.debian.org