Quote:
Originally Posted by sgala
My problem is that the device is recognized as device id 0fca:0006 and after some seconds it switch to 0fca:0004 . So when I make a "usb_add host:0fca:0006" QEMU lose my request and if I try to make a "usb_add host:0fca:004" the system forever wait something with the CPU at 100%.
|
Wow, what a cool idea.
I've not done it, but I can help with details I've learned from barry/bcharge that seem to be affecting you and maybe will help.
The change from 0006 -> 0004 is how the device works by design, it's the Desktop software sending a special USB message to the device to switch modes. 0006 is USB Mass Storage only - the default it will stay at with no Desktop software (well, really the USB drivers portion of it) or under regular Linux or Mac. The 0004 interface is a special dual mode; it has 4 'endpoints', supporting *both* Mass Storage and the control channel at the same time. (mode 0001 is control channel only).
It makes sense why 0006 is failing -- as soon as you plug in the device the USB drivers tell it to switch to 0004 mode; the only way you can stop this is to uninstall the BB Desktop/drivers software. :-/
It *sounds* like when you try and add the usb_host to 0004 it's trying to bind to the wrong endpoints - I'm not sure which ones it's after, but I'm guessing you want to bind the control channels, not the usb mass storage channels. Is there any way you can debug the usb_add command (strace, etc.) to see why it's pegging the CPU @ 100%?
ps: after plugging in the device, did you run "rmmod usb_storage" in linux before trying to use usb_add commands for QEMU?