Re: [Barry-devel] Setting alternate interface in Usb::Interface::Interface

[Toby G. <tob...@re...>]

  On 22/09/2010 11:36, Toby Gray wrote:
>    On 21/09/2010 23:01, Chris Frey wrote:
>> On Tue, Sep 21, 2010 at 12:12:57PM +0100, Toby Gray wrote:
>>> However there's clearly a reason for the call to usb_set_altinterface,
>>> so can anyone remember what devices it was necessary for?
>> It wasn't a specific device, it was all devices, I believe.  It was to work
>> around a change in the kernel, which caused odd timeout issues.  Also,
>> this fix made things work on Mac OSX and FreeBSD.
>>
>> The usb_set_altinterface() call is the only one in libusb that
>> works directly with the interface, as far as I can tell.
>>
>> You can read the long, painstaking thread here.  I ended up doing
>> a git-bisect on the kernel to find the spot where it was having trouble.
>>
>> 	http://marc.info/?t=123554440300001&r=1&w=2
>>
>> Especially here, where Alan Stern says that calling set_altinterface()
>> should always be safe.
>>
>> 	http://marc.info/?l=linux-usb&m=123627088604495&w=2
>>
> Thanks for those links. It sounds like setting the alternate setting to
> 0 for the interface is needed to make the connection work reliably, but
> that setting the alternate setting when URBs are outstanding on the
> other (usb-storage) interface really confuses most BlackBerry devices
> (although luckily not newer OSv5 ones as far as I can tell).
>
> It's odd that I don't see the original issue described in the above
> thread on my Ubuntu 10.04 machine running 2.6.32, but as it was always a
> timing related issue that doesn't seem too surprising.
I've been able to reproduce this only in QEMU VMs (hosting on Ubuntu 
10.04). Using VirtualBox as a VM (with Windows XP or Ubuntu 10.04 as 
host) leads to Barry not working at all (which is probably something to 
do with GET CONFIGURATION and SET INTERFACE requests never appearing in 
host USBmon traces).

I've had a play around with various other attempts at coming up with 
something which fixes the probe timeout issue and doesn't cause 
usb-storage to break and have had success with the following options:

1) Keep it how it is. If there is detection of 0 byte reads then it's 
now immediately obvious to users of Barry when the port has been reset, 
which is a considerably better user experience than hanging until the 
timeout occurs.
2) Change the probing code in src/probe.cc so that it tries probing the 
end points without a call to SET INTERFACE and then, if those probes 
fail, calls SET INTERFACE and probes again. I think it's probably best 
to probe all the end points and then call SET INTERFACE, rather than 
doing a probe, SET INTERFACE, and then a re-probe for each end point in 
turn. This would still have the usb-storage issue, but only for users 
where calling SET INTERFACE is necessary.
3) Use Paul O'Keefe's original usleep(100000) patch to solve this issue. 
This doesn't seem a great idea as arbitrary sleeps in code always worry 
me and this doesn't solve the issue for me in the VM.
4) Removing the calls to ClearHalt in Probe::PairProbe() and 
Controller::SetupUsb() also fixes this issue without needing to call SET 
INTERFACE. However the calls to ClearHalt are there to support the 8830 
which does need them, so I'd suggest having the Probe::PairProbe() try 
to probe without clearing halt and then, if that fails, retrying after 
clearing halt. The ProbeResult would then contain whether clearing halt 
was necessary or not for that device, which would be used by 
Controller::SetupUsb() to determine if ClearHalt should be called.

What's your feeling on which of these options is best? I would 
personally favour 4 as it seems to work nicely on the range of 
BlackBerry devices that I've tried.

Regards,

Toby