[sane-devel] MP730 driver broken since pixma-0.12.2
Nicolas
nicolas0martin at gmail.com
Wed Apr 22 16:16:26 UTC 2009
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>
> >>>
> >>>
> >>
> >>
> >>
> >>
>
>
>
>
More information about the sane-devel
mailing list