[sane-devel] sane to work with USB 3.0

[m. allan noah]

Excellent. Now, I am just worried that this will cause problems for
scanners attached to an ehci_hcd controlled port. We are unable to
determine from user space which driver is in use, so the modification
I made runs for any device, even those that don't need it.
Fortunately, the command is supposed to be a no-op, so maybe we will
be lucky.

allan

On Wed, Dec 17, 2014 at 7:41 AM, Gerhard Jäger <gerhard at gjaeger.de> wrote:
> 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 <kitno455 at gmail.com> wrote:
>> > On Thu, Dec 11, 2014 at 2:21 AM, Olaf Meeuwissen
>> >
>> > <olaf.meeuwissen at 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"
>



-- 
"well, I stand up next to a mountain- and I chop it down with the edge
of my hand"