[sane-devel] xerox_mfp usb malfunction

Warren Turkal wt at penguintechs.org
Tue Mar 8 08:16:49 UTC 2011

Responses below.

On Tue, Mar 8, 2011 at 1:13 AM, m. allan noah <kitno455 at gmail.com> wrote:
> Thanks for the patch. I must confess I don't quite understand the
> code.

A lot of the lines of code just added debugging output so that I could
see what functions were being called as I find the code pretty
difficult to follow. IIRC, the business part of the patch deletes one
line and adds 2.

> If the caller provides a device name which does not exactly
> exist, I think the backend should just return an error, instead of
> trying to find a similarly named device. There is no guarantee that
> device names will have a consistent format on all systems.

What's happening is a little more subtle. For each line in the
xerox_mfp.conf file, the line is processed via the call
"sanei_usb_attach_matching_devices (devname, attach);". The "attach"
arg is a function pointer that is provided by the backend to actually
make the backend recognize the device as a device handled by the
backend. That "sanei_usb_attach_matching_devices (devname, attach);"
call checks that the letters "usb" are the first three of the string.
Assuming that it the case, it extracts the vendor and product ids and
calls "sanei_usb_find_devices (vendorID, productID, attach);" I lose
the trail there thanks to a spaghetti mess of code involving global
variables and mixed tabs and spaces.

For my device (vendor id: 0x04e8 and product id: 0x3440) somehow via
magic, list_one_device("libusb:0x04e8 0x3440") is called. This is the
attach function in those previous calls. This function expects usb as
the first three letters of the passed string for a device that is USB.
Since the first three letters are "lib", of course it fails. This
expectation is setup by the "available_transports" array. However, I
can't just change "usb" to "libusb", because it is also used to
determine whether to call "sanei_usb_attach_matching_devices (devname,
attach);" in the first place.

This is a huge mess that really needs to be cleaned up. My workaround
just assumes that if the first six letters of the devname string are
libusb, then it should be handled as a usb device. While it
technically works, I believe this to be a less optimal solution can
doing so serious reworking to the code to make it more clear how this

My workaround is also specific to the xerox_mfp backend, and it's
possible that other backends using the functions from sanei_usb could
also be affected.

> Perhaps the author will comment.

I don't expect to hear anything from the author as there are a couple
folks who touched this backend code over that past few years, but
maybe I'll be pleasantly surprised. :)

I hope this clears up what the patch is doing to some degree.


More information about the sane-devel mailing list