Re: [Qemu-devel] Large USB patch

[Lonnie Mendez <lmendez19@austin.rr.com>]

nix.wie.weg@gmx.de wrote:

   lo

>Yes I am absolutly sure we need this changes. The usb protocoll is a
>very sophisticated work. There is an exactly defined sequence in which
>packets are send. (I have made some small documentation about this:
>http://217.20.126.200/tino/usb-order-of-events.pdf
>http://217.20.126.200/tino/usb-order-of-events.odg)
>If you do not keep track of this, you will never be able to get most
>devices running. The qemu-specialcase-1.patch is the result of ignoring
>these sequence. At the moment I'm not even sure, if we have to implement
>the states in which a device is in (I mean default state, adress state
>... USB Spec. 1.1 chapter 9).
>  
>
   Well I'm glad someone took a deeper look at it.  I never addressed it 
as a correct solution to the problem.  And indeed with the patch applied 
the transaction log is clean.

>>>changed the handling of special messages like usb_reset or usb_attach
>>>8. I made the necessary changes to usb-hid.c and usb-hub.c
>>>9. I wrote a lot of source comments
>>> 
>>>
>>>      
>>>
>>  I'm in favor of a new api but with only one controller there is
>>almost no point in doing this yet.  
>>    
>>
>Sorry I can't agree on that point with you. We will get more
>controller/devices if we can provide an easy api for implementing them.
>I would really be interrested  to see an EHCI Controller - maybe I will
>even implement it by myself.
>  
>
   Sounds good.  Not sure what I was going on about there.

>>It may make more sense to either be able to specify either grabbing
>>all or a few interfaces to proxy to the guest.  Also, libusb is ok for
>>a generic handler, but there is no way you'll get someone to jump
>>through all the hoops necessary to get usb working under windows with
>>libusb-win32 or even mac os x.  On win32 host you have to manually
>>create an inf file with the PID/VID and then install that for every
>>device you try to use.  It's not a good idea to use the filter driver
>>unless the corresponding host driver is unbinded (especially for mass
>>storage).  On mac os x you would supposedly creates codeless kernel
>>extensions with the PID/VID to unbind the device.  That could be done
>>through scripts, but none exist.
>>
>>    
>>
>On that point you have probably misunderstood me. I dont want to
>liquidate any native usb-host files. On the contrary, with that patch it
>is easier to get more such native interfaces running. We could even
>implement on some platforms more than one interface. I for instance
>would like it, if I could have libusb and linux native support enabled
>at the same time so I could make such things like:
>$ qemu -usb controller=uhci -usb device=libusb:002:003,addto=001:001
>-usb device=linux:001:002,addto=001:002
>and it should now not be so difficult to implement.
>  
>
   Yes, I have misunderstood you.  It sounds like a good plan.  I'll 
ready the bsd redirector around the api tomorrow if possible.  From some 
limited testing it fails rather early on a linux guest so it shouldn't 
be too hard to fix on that.  There is quite a bit here and the person 
that would merge this into CVS is Fabrice Bellard.  He would have to 
review all this before it ever touches CVS.