Allan, you're da man ;)
I've just pulled the updated sources, built and installed. Plugged in my CanoScan LiDE30 (plustek-backend) to a USB 3 port: usb 3-1: USB disconnect, device number 2 usb 3-1: new full-speed USB device number 3 using xhci_hcd usb 3-1: New USB device found, idVendor=04a9, idProduct=220e usb 3-1: New USB device strings: Mfr=64, Product=77, SerialNumber=0 usb 3-1: Product: CanoScan usb 3-1: Manufacturer: Canon And it seems to fix the issues that have been observed with the plustek backend. Thanks for taking care, Gerhard On Tuesday 16 December 2014 10:33:14 m. allan noah wrote: > I have just committed an attempted workaround for this Linux kernel > bug. I have tested with Fujitsu and Canon scanners, and it does fix > the problem. I have not tested with other scanners. We need as much > testing on this as we can get. Please build from a current git > checkout (or tomorrow's git snapshot), and let us know what you find. > > allan > > On Thu, Dec 11, 2014 at 9:05 PM, m. allan noah <kitno...@gmail.com> wrote: > > On Thu, Dec 11, 2014 at 2:21 AM, Olaf Meeuwissen > > > > <olaf.meeuwis...@avasys.jp> wrote: > >> m. allan noah writes: > >>> I have just pushed your patches to git. They don't seem to help with > >>> any scanner that I have, but I doubt they will hurt anything. > >> > >> Thanks! > >> > >>> It appears that we also have USB3 issues with Canon scanners as well- > >>> they do use clear_halt frequently, and it seems that maybe the Linux > >>> kernel is not passing them down to the scanner in some cases. > >> > >> Do they halt/stall that frequently? If there's no stall, clear_halt > >> should not be used, IIUC. Hmm, it doesn't look like sanei_usb allows > >> you to find out about that ... > > > > Yeah, the Canon machines halt at the drop of a hat. I added > > sanei_usb_clear_halt specifically for them. > > > > But, no matter. Based on the threads linked from this post: > > http://www.spinics.net/lists/linux-usb/msg105515.html I have come up > > with a workaround that fixes both the Canon and the Fujitsu machines I > > have access to. It seems the xhci controller refuses to transmit a > > clear_halt to the device or reset the data 0/1 toggle in the host when > > the ehci controller would. However, sending a set_interface command > > for the interface that is already selected, seems to do both of those > > things. So, I added a call to > > > > sanei_usb_set_altinterface (s->fd, 0); > > > > right before the calls to sanei_usb_close() or sanei_usb_clear_halt() > > in those two backends, and everything suddenly seems to work. > > > > I need to do some further testing, and see if these changes should be > > moved up to sanei_usb instead of the backends. > > > > allan > > -- > > "well, I stand up next to a mountain- and I chop it down with the edge > > of my hand" -- sane-devel mailing list: sane-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject "unsubscribe your_password" to sane-devel-requ...@lists.alioth.debian.org
