[sane-devel] MP730 driver broken since pixma-0.12.2

Wade Fitzpatrick wade.fitzpatrick at gmail.com
Thu Apr 23 15:19:35 UTC 2009


Hi Nicolas

Thanks for reviewing my patches. I have to agree with you... too many late
nights... must be coding in my sleep...

   1. 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.
   2. 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.
   3. 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.

The only problems I can find now are:

   1. 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.
   2. 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.

Does this hold true for other models too?
Does batch mode succeed on other models with ADF?

I can't believe I've spent so much time on such a trivial change :(

Regards,
Wade.


2009/4/23 Nicolas <nicolas0martin at gmail.com>

> Hi Wade,
>
> Good news that you succeeded in having your MP730 work after 2,5 years !
>
> 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:
>
> 1/ File backend/pixma_mp730.c
>
> I don't understand the change you've brought here individually for each
> device, the line that you replaced for MP730:
>
> -  DEVICE ("Canon MultiPASS MP730", "MP730", MP730_PID, 1200, 637, 868,
> PIXMA_CAP_ADF),
> +  DEVICE ("Canon MultiPASS MP730", "MP730", MP730_PID, 1200, 637, 868,
> PIXMA_CAP_ADF|PIXMA_CAP_EVENTS),
>
> has exactly the same effect than the original one in the device definition:
> -        PIXMA_CAP_GRAY|PIXMA_CAP_EVENTS|cap           \
> +              PIXMA_CAP_GRAY|cap /* capabilities */          \
>
> Here, you move the PIXMA_CAP_EVENTS flag from the global device definition
> to the individual definition of each device.
>
> - For MP730, this looks to have the same effect, or where is the difference
> ?
> - But this changes the definition for all other devices here, and I would
> not like to bring here any regression to other devices.
>
> So: could you give the motivation for this modification here ?
>
> 2/ file pixma_io_sanei.c
>
> The only diff I see here adds a PDBG debug statement:
> + PDBG (pixma_dbg (3, "sanei_usb_read_bulk returned error code: %i\n",
> error));
>
> The other line is a commented line:
>
> +      /*error = pixma_map_status_errno (pixma_get_be16 (buf)); */
>
> And I don't understand the comment you added:
> "The call to |pixma_map_status_errno() in
> |backend/pixma_io_sane.c:pixma_read()
> is in the wrong place as |pixma_read() may be re-entrant so as to read a
> partial buffer."
>
> - There are _no_ calls to |pixma_map_status_errno() in current cvs
> ||pixma_read()
> The one here is added as part of you modifications, but is commented out.
> - This part of the pixma code is common to all pixma devices
> - The modifications you added here do not bring any functional change.
>
> So one again, what are those changes for ?
>
> 3/ File sanei_usb.c
>
> This is the only file where modifications appear to have a functional
> impact:
> |+                 /* don't try to read non-scanner device classes */
> +                 if (interface->bInterfaceClass == 0x07) {
> +                   DBG (3, "sanei_usb_open: skipping Printer
> interface\n");
> +                   continue;
> +                 }
> +                 if (interface->bInterfaceClass == 0x08) {
> +                   DBG (3, "sanei_usb_open: skipping Mass Storage
> interface\n");
> +                   continue;
> +                 }
> +                 if (interface->bInterfaceClass == 0xff && i == 3) {
> +                   DBG (3, "sanei_usb_open: skipping second Vendor
> Specific interface\n");
> +                   continue;
> +                 }
>
> 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
> supported by Sane, not only pixma.
> As for the 1.0.20 release, I would not recommend to add this change now, as
> it probably needs deeper testing and understanding.
>
> In other words, to step further, Wade:
> Could you give a try with the current Sane CVS files and patch only file
> sanei_usb.c, see if it is still ok?
> 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.
>
> Nicolas
>
>
> Wade Fitzpatrick a écrit :
>
>>  And now consistent success. See
>>  http://waddles.org/content/sane-canon-mp730-driver#5 UPDATE 5.
>>
>>  Unfortunately the patch needs more work and I don't think I'm going
>>  to have time to get it ready for the 1.0.20 release next week unless
>>  Nicolas whips up something.
>>
>>  Anyway, at least we know where the problems are now.
>>
>>  Cheers, Wade.
>>
>>  2009/4/19 Wade Fitzpatrick <wade.fitzpatrick at gmail.com
>>  <mailto:wade.fitzpatrick at gmail.com>>
>>
>>  Woohoo! Partial success. Updates at
>>  http://waddles.org/content/sane-canon-mp730-driver
>>
>>  Perhaps the discussion of sanei_usb belongs in a different thread :)
>>
>>  Cheers, Wade.
>>
>>  2009/4/19 Nicolas Martin <nicolas.martin at freesurf.fr
>>  <mailto:nicolas.martin at freesurf.fr>>
>>
>>  Maybe there's some relation with the endpoint, but remember that all
>>  PIXMA devices have also different endpoints for storage, printer and
>>  scanner, and there's no issue so far with messing those devices. So
>>  this requires anyway deeper analysis, but filtering out usb classes
>>  in sanei_usb is a good precaution.
>>
>>  BTW, we really read your posts and try to figure out where there's
>>  something wrong, but as you can understand, this usb issue is not
>>  trivial.
>>
>>  Nicolas
>>
>>  Le dimanche 19 avril 2009 à 03:46 +1000, Wade Fitzpatrick a écrit :
>> > The patch should apply to current if somebody wants to test it. I
>> > just don't know how many scanners might be attached to Printer or
>> > Mass Storage devices' interfaces so I deliberately left it simple,
>> > but the extra debug info was certainly helpful.
>> >
>> > Glad to see somebody is still reading my post, anyway. Thanks.
>> >
>> > Wade.
>> >
>> > m. allan noah wrote:
>> >> though i must chime in that wade's latest post is very
>> >> interesting- it does appear that sanei_usb grabs the wrong
>> >> interface. I believe Ilia had a complaint about this as well.
>> >> Sounds like sanei_usb needs an overhaul after our next release.
>> >>
>> >> allan
>> >>
>> >> On Sat, Apr 18, 2009 at 12:57 PM, Nicolas Martin
>> >> <nicolas.martin at freesurf.fr <mailto:nicolas.martin at freesurf.fr>>
>>
>> >> wrote:
>> >>
>> >>> Wade,
>> >>>
>> >>> As far as I can see, you are experiencing a usb interrupt
>> >>> transfer issue, same kind as happened to other people when
>> >>> running the pixma backend on an ASUS router or also on MAC OS
>> >>> X.
>> >>>
>> >>> What is important to know is that the pixma backend - and this
>> >>> is due to Canon's PIXMA devices - make use of both usb Bulk
>> >>> read/write transfers, and also of usb Interrupt read transfers.
>> >>>
>> >>>
>> >>> It is compulsory that usb interrupt read transfers fully work
>> >>> to operate the pixma backend, as the scanner (and more
>> >>> especially older PIXMA devices, like MP730) uses those transfer
>> >>> to exchange : - status information - time request - button scan
>> >>> information
>> >>>
>> >>> Today's PIXMA devices (that uses a generation 3 protocol) uses
>> >>> both, but can work without interrupt read ; in this case, only
>> >>> button scan will be disabled, but the scanner can be entirely
>> >>> driven with Bulk transfers. This is not the case for MP730, a
>> >>> generation 2 protocol device, which requires usb interrupt read
>> >>> transfers to be operated.
>> >>>
>> >>> There's a difference also between the usb lib used by Sane, and
>> >>> the one used in the pixma Standalone driver. Sane uses libusb,
>> >>> based on ioctl calls to the kernel to execute usb transfers,
>> >>> while standalone driver uses usbdevfs.
>> >>>
>> >>> In order to help you and step further, could you tell us which
>> >>> Linux distribution (and version) you are running ?
>> >>>
>> >>> $ uname -a
>> >>>
>> >>> As I told before, this kind of issue was due on MAC OS X to the
>> >>> darwin libusb port, not handling timeouts in interrupt reads,
>> >>> and for the ASUS router, use of a (very) old kernel 2.4.20
>> >>> version, known to be buggy for usb interrupt reads.
>> >>>
>> >>> Nicolas
>> >>>
>> >>>
>> >>> Le samedi 18 avril 2009 à 09:01 +1000, Wade Fitzpatrick a écrit
>> >>> :
>> >>>
>> >>>> I have updated my findings at
>> >>>> http://waddles.org/content/sane-canon-mp730-driver
>> >>>>
>> >>>> Can someone suggest the next place to start work?
>> >>>>
>> >>>> Thanks, Wade.
>> >>>>
>> >>>> 2009/4/4 Nicolas Martin <nicolas.martin at freesurf.fr
>> >>>> <mailto:nicolas.martin at freesurf.fr>> Sorry, posted answer in
>>
>> >>>> wrong thread.
>> >>>>
>> >>>> As far as I can see in the differences between older versions
>> >>>>  of the pixma standalone driver and today's, concerning usb
>> >>>> exchanges for MP730, the older drivers did not use events
>> >>>> polling whereas newer do with usb interrupt reads.
>> >>>>
>> >>>> First, did you try to remove the PIXMA_CAP_EVENTS flag for
>> >>>> the pixma 730 declaration (at the botom of file
>> >>>> pixma_mp730.c) and see how it behaves ?
>> >>>>
>> >>>> I will also send you some modified files for the pixma
>> >>>> backend to investigate why this usb low level error appears.
>> >>>>
>> >>>> Nicolas
>> >>>>
>> >>>> Le vendredi 03 avril 2009 à 03:14 +1100, Wade Fitzpatrick a
>> >>>> écrit :
>> >>>>
>> >>>>> Can you take a look at the logs on
>> >>>>> http://waddles.org/content/sane-canon-mp730-driver and tell
>> >>>>>
>> >>>> me if you
>> >>>>> think I'm on the right track with the endpoints?
>> >>>>>
>> >>>>> I CBF re-installing Windows, but I did test a successful
>> >>>> scan with
>> >>>>> mp150-0.12.2 followed immediately by a try with
>> >>>>> pixma-0.15.0
>> >>>> but it
>> >>>>> failed so I doubt it has anything to do with power-saving
>> >>>> modes.
>> >>>>>
>> >>>>> Thanks, Wade.
>> >>>>>
>> >>>>> 2009/3/21 Nicolas Martin <nicolas.martin at freesurf.fr
>> >>>>> <mailto:nicolas.martin at freesurf.fr>> Seems confirmed that a
>> >>>>> usb low level error happens
>> >>>> on first
>> >>>>> write attempt:
>> >>>>>
>> >>>>> [sanei_usb] sanei_usb_write_bulk: trying to write 10
>> >>>> bytes
>> >>>>> [sanei_usb] 000 F3 20 00 00 00 00 00 00 0C 00
>> >>>>> . ........ USB error: error submitting URB: Device or
>> >>>>> resource
>> >>>> busy
>> >>>>> [sanei_usb] sanei_usb_write_bulk: write failed:
>> >>>> Device or
>> >>>>> resource busy USB error: could not clear/halt ep 1: Device
>> >>>>> or
>> >>>> resource busy
>> >>>>>
>> >>>>> [pixma] WARNING:pixma_write(): count(0) != len(10)
>> >>>>>
>> >>>>>
>> >>>>> I remember having seen this before for someone else,
>> >>>> this
>> >>>>> happened when the usb port was going to power saving
>> >>>>> (generally
>> >>>> after a few
>> >>>>> seconds)
>> >>>>>
>> >>>>> Could it be the case on system ?
>> >>>>>
>> >>>>> Nicolas
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> >>> -- sane-devel mailing list: sane-devel at lists.alioth.debian.org
>> >>> <mailto:sane-devel at lists.alioth.debian.org>
>> >>> http://lists.alioth.debian.org/mailman/listinfo/sane-devel
>> >>> Unsubscribe: Send mail with subject "unsubscribe your_password"
>> >>>  to sane-devel-request at lists.alioth.debian.org
>> >>> <mailto:sane-devel-request at lists.alioth.debian.org>
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >>
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090424/40b579b6/attachment-0001.htm>


More information about the sane-devel mailing list