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 _______________________________________________ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"