Hi Nicolas<br><br>Thanks for reviewing my patches. I have to agree with you... too many late nights... must be coding in my sleep...<br><ol><li>I had the PIXMA_CAP_EVENTS flag removed at some stage as that's what got the driver working again between pixma-0.12.1 and pixma-0.12.2. It doesn't seem to make any difference now and I can't explain why so just ignore it. I don't think the resolution and maximum scan area parameters are correct but that's an issue for another day.<br>
</li><li>I don't remember adding that line but I guess I must have. It may have been an accidental 'p' in vim. Ignore this one too.</li><li>I checked out a fresh new cvs today and applied just the lines you pasted below to sanei/sanei_usb.c - it works just fine with that change alone. I ran through about 30 successful tests too: using ADF, button-controlled, ADF+button-controlled, Gray, Color and at various resolutions and geometries on and off the platen glass, pressing Cancel during a scan, pressing Ctrl-C during a scan, jamming the paper in the ADF, batch scans etc.<br>
</li></ol>The only problems I can find now are:<br><ol><li>Scanning at 1200dpi Grayscale. Sometimes it hangs depending on the x and y values - the larger the values, the sooner it fails. If it does succeed, the data is always bogus.</li>
<li>The return code after a successful scan is always ECANCELED which causes a problem for batch mode as it will only scan one page. It doesn't seem to matter for single scans.</li></ol>Does this hold true for other models too?<br>
Does batch mode succeed on other models with ADF?<br><br>I can't believe I've spent so much time on such a trivial change :(<br><br>Regards,<br>Wade.<br><ol>
</ol><div class="gmail_quote">2009/4/23 Nicolas <span dir="ltr"><<a href="mailto:nicolas0martin@gmail.com" target="_blank">nicolas0martin@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Wade,<br>
<br>
Good news that you succeeded in having your MP730 work after 2,5 years !<br>
<br>
I did carefully inspect the small changes you have done to the pixma backend, but there are some points I don't understand clearly, or maybe I've missed sthg, but you can surely give us some more info here:<br>
<br>
1/ File backend/pixma_mp730.c<br>
<br>
I don't understand the change you've brought here individually for each device, the line that you replaced for MP730:<br>
<br>
- DEVICE ("Canon MultiPASS MP730", "MP730", MP730_PID, 1200, 637, 868, PIXMA_CAP_ADF),<br>
+ DEVICE ("Canon MultiPASS MP730", "MP730", MP730_PID, 1200, 637, 868, PIXMA_CAP_ADF|PIXMA_CAP_EVENTS),<br>
<br>
has exactly the same effect than the original one in the device definition:<br>
- PIXMA_CAP_GRAY|PIXMA_CAP_EVENTS|cap \<br>
+ PIXMA_CAP_GRAY|cap /* capabilities */ \<br>
<br>
Here, you move the PIXMA_CAP_EVENTS flag from the global device definition to the individual definition of each device.<br>
<br>
- For MP730, this looks to have the same effect, or where is the difference ?<br>
- But this changes the definition for all other devices here, and I would not like to bring here any regression to other devices.<br>
<br>
So: could you give the motivation for this modification here ?<br>
<br>
2/ file pixma_io_sanei.c<br>
<br>
The only diff I see here adds a PDBG debug statement:<br>
+ PDBG (pixma_dbg (3, "sanei_usb_read_bulk returned error code: %i\n", error));<br>
<br>
The other line is a commented line:<br>
<br>
+ /*error = pixma_map_status_errno (pixma_get_be16 (buf)); */<br>
<br>
And I don't understand the comment you added:<br>
"The call to |pixma_map_status_errno() in |backend/pixma_io_sane.c:pixma_read()<br>
is in the wrong place as |pixma_read() may be re-entrant so as to read a partial buffer."<br>
<br>
- There are _no_ calls to |pixma_map_status_errno() in current cvs ||pixma_read()<br>
The one here is added as part of you modifications, but is commented out.<br>
- This part of the pixma code is common to all pixma devices<br>
- The modifications you added here do not bring any functional change.<br>
<br>
So one again, what are those changes for ?<br>
<br>
3/ File sanei_usb.c<br>
<br>
This is the only file where modifications appear to have a functional impact:<br>
|+ /* don't try to read non-scanner device classes */<br>
+ if (interface->bInterfaceClass == 0x07) {<br>
+ DBG (3, "sanei_usb_open: skipping Printer interface\n");<br>
+ continue;<br>
+ }<br>
+ if (interface->bInterfaceClass == 0x08) {<br>
+ DBG (3, "sanei_usb_open: skipping Mass Storage interface\n");<br>
+ continue;<br>
+ }<br>
+ if (interface->bInterfaceClass == 0xff && i == 3) {<br>
+ DBG (3, "sanei_usb_open: skipping second Vendor Specific interface\n");<br>
+ continue;<br>
+ }<br>
<br>
As Allan pointed out, this may need some deeper analysis to the sanei_usb code, but modifications in this file are very sensitive, as they impact all usb devices<br>
supported by Sane, not only pixma.<br>
As for the 1.0.20 release, I would not recommend to add this change now, as it probably needs deeper testing and understanding.<br>
<br>
In other words, to step further, Wade:<br>
Could you give a try with the current Sane CVS files and patch only file sanei_usb.c, see if it is still ok?<br>
If not, this means there's something I did not catch, so we'll need to talk again to finalize the changes, if any, required for MP730.<br>
<br>
Nicolas<br>
<br>
<br>
Wade Fitzpatrick a écrit :<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>
And now consistent success. See<br>
<a href="http://waddles.org/content/sane-canon-mp730-driver#5" target="_blank">http://waddles.org/content/sane-canon-mp730-driver#5</a> UPDATE 5.<br>
<br>
Unfortunately the patch needs more work and I don't think I'm going<br>
to have time to get it ready for the 1.0.20 release next week unless<br>
Nicolas whips up something.<br>
<br>
Anyway, at least we know where the problems are now.<br>
<br>
Cheers, Wade.<br>
<br>
2009/4/19 Wade Fitzpatrick <<a href="mailto:wade.fitzpatrick@gmail.com" target="_blank">wade.fitzpatrick@gmail.com</a><br></div>
<mailto:<a href="mailto:wade.fitzpatrick@gmail.com" target="_blank">wade.fitzpatrick@gmail.com</a>>><div><br>
<br>
Woohoo! Partial success. Updates at<br>
<a href="http://waddles.org/content/sane-canon-mp730-driver" target="_blank">http://waddles.org/content/sane-canon-mp730-driver</a><br>
<br>
Perhaps the discussion of sanei_usb belongs in a different thread :)<br>
<br>
Cheers, Wade.<br>
<br>
2009/4/19 Nicolas Martin <<a href="mailto:nicolas.martin@freesurf.fr" target="_blank">nicolas.martin@freesurf.fr</a><br></div>
<mailto:<a href="mailto:nicolas.martin@freesurf.fr" target="_blank">nicolas.martin@freesurf.fr</a>>><div><br>
<br>
Maybe there's some relation with the endpoint, but remember that all<br>
PIXMA devices have also different endpoints for storage, printer and<br>
scanner, and there's no issue so far with messing those devices. So<br>
this requires anyway deeper analysis, but filtering out usb classes<br>
in sanei_usb is a good precaution.<br>
<br>
BTW, we really read your posts and try to figure out where there's<br>
something wrong, but as you can understand, this usb issue is not<br>
trivial.<br>
<br>
Nicolas<br>
<br>
Le dimanche 19 avril 2009 à 03:46 +1000, Wade Fitzpatrick a écrit :<br>
> The patch should apply to current if somebody wants to test it. I<br>
> just don't know how many scanners might be attached to Printer or<br>
> Mass Storage devices' interfaces so I deliberately left it simple,<br>
> but the extra debug info was certainly helpful.<br>
><br>
> Glad to see somebody is still reading my post, anyway. Thanks.<br>
><br>
> Wade.<br>
><br>
> m. allan noah wrote:<br>
>> though i must chime in that wade's latest post is very<br>
>> interesting- it does appear that sanei_usb grabs the wrong<br>
>> interface. I believe Ilia had a complaint about this as well.<br>
>> Sounds like sanei_usb needs an overhaul after our next release.<br>
>><br>
>> allan<br>
>><br>
>> On Sat, Apr 18, 2009 at 12:57 PM, Nicolas Martin<br></div>
>> <<a href="mailto:nicolas.martin@freesurf.fr" target="_blank">nicolas.martin@freesurf.fr</a> <mailto:<a href="mailto:nicolas.martin@freesurf.fr" target="_blank">nicolas.martin@freesurf.fr</a>>><div><div>
</div><div><br>
>> wrote:<br>
>><br>
>>> Wade,<br>
>>><br>
>>> As far as I can see, you are experiencing a usb interrupt<br>
>>> transfer issue, same kind as happened to other people when<br>
>>> running the pixma backend on an ASUS router or also on MAC OS<br>
>>> X.<br>
>>><br>
>>> What is important to know is that the pixma backend - and this<br>
>>> is due to Canon's PIXMA devices - make use of both usb Bulk<br>
>>> read/write transfers, and also of usb Interrupt read transfers.<br>
>>><br>
>>><br>
>>> It is compulsory that usb interrupt read transfers fully work<br>
>>> to operate the pixma backend, as the scanner (and more<br>
>>> especially older PIXMA devices, like MP730) uses those transfer<br>
>>> to exchange : - status information - time request - button scan<br>
>>> information<br>
>>><br>
>>> Today's PIXMA devices (that uses a generation 3 protocol) uses<br>
>>> both, but can work without interrupt read ; in this case, only<br>
>>> button scan will be disabled, but the scanner can be entirely<br>
>>> driven with Bulk transfers. This is not the case for MP730, a<br>
>>> generation 2 protocol device, which requires usb interrupt read<br>
>>> transfers to be operated.<br>
>>><br>
>>> There's a difference also between the usb lib used by Sane, and<br>
>>> the one used in the pixma Standalone driver. Sane uses libusb,<br>
>>> based on ioctl calls to the kernel to execute usb transfers,<br>
>>> while standalone driver uses usbdevfs.<br>
>>><br>
>>> In order to help you and step further, could you tell us which<br>
>>> Linux distribution (and version) you are running ?<br>
>>><br>
>>> $ uname -a<br>
>>><br>
>>> As I told before, this kind of issue was due on MAC OS X to the<br>
>>> darwin libusb port, not handling timeouts in interrupt reads,<br>
>>> and for the ASUS router, use of a (very) old kernel 2.4.20<br>
>>> version, known to be buggy for usb interrupt reads.<br>
>>><br>
>>> Nicolas<br>
>>><br>
>>><br>
>>> Le samedi 18 avril 2009 à 09:01 +1000, Wade Fitzpatrick a écrit<br>
>>> :<br>
>>><br>
>>>> I have updated my findings at<br>
>>>> <a href="http://waddles.org/content/sane-canon-mp730-driver" target="_blank">http://waddles.org/content/sane-canon-mp730-driver</a><br>
>>>><br>
>>>> Can someone suggest the next place to start work?<br>
>>>><br>
>>>> Thanks, Wade.<br>
>>>><br>
>>>> 2009/4/4 Nicolas Martin <<a href="mailto:nicolas.martin@freesurf.fr" target="_blank">nicolas.martin@freesurf.fr</a><br></div></div>
>>>> <mailto:<a href="mailto:nicolas.martin@freesurf.fr" target="_blank">nicolas.martin@freesurf.fr</a>>> Sorry, posted answer in<div><div></div><div><br>
>>>> wrong thread.<br>
>>>><br>
>>>> As far as I can see in the differences between older versions<br>
>>>> of the pixma standalone driver and today's, concerning usb<br>
>>>> exchanges for MP730, the older drivers did not use events<br>
>>>> polling whereas newer do with usb interrupt reads.<br>
>>>><br>
>>>> First, did you try to remove the PIXMA_CAP_EVENTS flag for<br>
>>>> the pixma 730 declaration (at the botom of file<br>
>>>> pixma_mp730.c) and see how it behaves ?<br>
>>>><br>
>>>> I will also send you some modified files for the pixma<br>
>>>> backend to investigate why this usb low level error appears.<br>
>>>><br>
>>>> Nicolas<br>
>>>><br>
>>>> Le vendredi 03 avril 2009 à 03:14 +1100, Wade Fitzpatrick a<br>
>>>> écrit :<br>
>>>><br>
>>>>> Can you take a look at the logs on<br>
>>>>> <a href="http://waddles.org/content/sane-canon-mp730-driver" target="_blank">http://waddles.org/content/sane-canon-mp730-driver</a> and tell<br>
>>>>><br>
>>>> me if you<br>
>>>>> think I'm on the right track with the endpoints?<br>
>>>>><br>
>>>>> I CBF re-installing Windows, but I did test a successful<br>
>>>> scan with<br>
>>>>> mp150-0.12.2 followed immediately by a try with<br>
>>>>> pixma-0.15.0<br>
>>>> but it<br>
>>>>> failed so I doubt it has anything to do with power-saving<br>
>>>> modes.<br>
>>>>><br>
>>>>> Thanks, Wade.<br>
>>>>><br>
>>>>> 2009/3/21 Nicolas Martin <<a href="mailto:nicolas.martin@freesurf.fr" target="_blank">nicolas.martin@freesurf.fr</a><br></div></div>
>>>>> <mailto:<a href="mailto:nicolas.martin@freesurf.fr" target="_blank">nicolas.martin@freesurf.fr</a>>> Seems confirmed that a<div><br>
>>>>> usb low level error happens<br>
>>>> on first<br>
>>>>> write attempt:<br>
>>>>><br>
>>>>> [sanei_usb] sanei_usb_write_bulk: trying to write 10<br>
>>>> bytes<br>
>>>>> [sanei_usb] 000 F3 20 00 00 00 00 00 00 0C 00<br>
>>>>> . ........ USB error: error submitting URB: Device or<br>
>>>>> resource<br>
>>>> busy<br>
>>>>> [sanei_usb] sanei_usb_write_bulk: write failed:<br>
>>>> Device or<br>
>>>>> resource busy USB error: could not clear/halt ep 1: Device<br>
>>>>> or<br>
>>>> resource busy<br>
>>>>><br>
>>>>> [pixma] WARNING:pixma_write(): count(0) != len(10)<br>
>>>>><br>
>>>>><br>
>>>>> I remember having seen this before for someone else,<br>
>>>> this<br>
>>>>> happened when the usb port was going to power saving<br>
>>>>> (generally<br>
>>>> after a few<br>
>>>>> seconds)<br>
>>>>><br>
>>>>> Could it be the case on system ?<br>
>>>>><br>
>>>>> Nicolas<br>
>>>>><br>
>>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>><br>
>>> -- sane-devel mailing list: <a href="mailto:sane-devel@lists.alioth.debian.org" target="_blank">sane-devel@lists.alioth.debian.org</a><br></div>
>>> <mailto:<a href="mailto:sane-devel@lists.alioth.debian.org" target="_blank">sane-devel@lists.alioth.debian.org</a>><div><br>
>>> <a href="http://lists.alioth.debian.org/mailman/listinfo/sane-devel" target="_blank">http://lists.alioth.debian.org/mailman/listinfo/sane-devel</a><br>
>>> Unsubscribe: Send mail with subject "unsubscribe your_password"<br>
>>> to <a href="mailto:sane-devel-request@lists.alioth.debian.org" target="_blank">sane-devel-request@lists.alioth.debian.org</a><br></div>
>>> <mailto:<a href="mailto:sane-devel-request@lists.alioth.debian.org" target="_blank">sane-devel-request@lists.alioth.debian.org</a>><br>
>>><br>
>>><br>
>><br>
>><br>
>><br>
>><br>
<br>
<br>
<br>
<br>
</blockquote>
<br>
</blockquote></div><br>