From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FWph3-00056z-Si for qemu-devel@nongnu.org; Fri, 21 Apr 2006 03:04:41 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FWph2-000535-03 for qemu-devel@nongnu.org; Fri, 21 Apr 2006 03:04:41 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FWph1-00052m-OG for qemu-devel@nongnu.org; Fri, 21 Apr 2006 03:04:39 -0400 Received: from [24.93.47.44] (helo=ms-smtp-05.texas.rr.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FWpiW-0006yR-MY for qemu-devel@nongnu.org; Fri, 21 Apr 2006 03:06:12 -0400 Received: from [192.168.0.11] (cpe-67-9-160-120.austin.res.rr.com [67.9.160.120]) by ms-smtp-05.texas.rr.com (8.13.4/8.13.4) with ESMTP id k3L74bLG008915 for ; Fri, 21 Apr 2006 02:04:38 -0500 (CDT) Message-ID: <44488404.8010800@austin.rr.com> Date: Fri, 21 Apr 2006 02:04:36 -0500 From: Lonnie Mendez MIME-Version: 1.0 Subject: Re: [Qemu-devel] Large USB patch References: <4447E811.1040403@gmx.de> <44484217.1030309@austin.rr.com> <444874B0.3070905@gmx.de> In-Reply-To: <444874B0.3070905@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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.