SANE vs USB scanner on 8.0

[Andrew Reilly]

On Mon, Jan 25, 2010 at 02:57:21PM +1100, Andrew Reilly wrote:
> On Sun, Jan 24, 2010 at 09:32:43AM -0700, Warren Block wrote:
> > Understood.  It looks like it's going to take some work on the backend 
> > for that to happen.  As Hans said, best to file a bug report at 
> > http://www.sane-project.org/bugs.html.
> 
> For what it's worth, I appear to be in exactly the same
> situation as Torfinn, with my snapscan-e20.  I've now run the
> back-end with the SANE_DEBUG_SNAPSCAN env set to 255, and it is
> clear that it is running into the same device string parsing
> issue:

OK, I've "fixed" my copy of the snapscan backend, to behave
nicely with FreeBSD's new libusb.  Here's my patch, to be
applied in /usr/ports/graphics/sane-backends/work/sane-backends-1.0.20/backend:

--- snapscan-mutex.c.orig	2008-03-29 07:39:02.000000000 +1100
+++ snapscan-mutex.c	2010-01-25 15:36:47.000000000 +1100
@@ -130,7 +130,7 @@
 	    return 0;
 	}
 
-	if (sscanf(dev, "libusb:%d:%d", &busnum, &devnum) != 2)
+	if (sscanf(dev, "libusb:/dev/usb:/dev/ugen%d.%d", &busnum, &devnum) != 2)
 	{
 	    DBG (DL_MAJOR_ERROR, "%s: could not parse device string: %s\n", me, strerror(errno));
 	    return 0;

As you can see, this is pretty stupid: it looks as though the
snapscan driver was trying to extract the bus number and device
number from the libusb device string, so that it could use it to
uniquify the SysV-IPC semaphore key it is about to generate.  I
suspect that anything that caused this test to not fail would
have worked just as well.

I don't have a login on the sane-project.org bug list mentioned
above, so if someone who does wouldn't mind adding this info to
the aforementioned bug, I'm sure someone would appreciate it.

In the mean-time, I'll submit a pr on the FreeBSD ports list, in
the hope that a ports patch might work in lieu of an up-stream
fix.

Cheers,

-- 
Andrew