From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FWlIs-00068C-V2 for qemu-devel@nongnu.org; Thu, 20 Apr 2006 22:23:27 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FWlIq-00067l-9b for qemu-devel@nongnu.org; Thu, 20 Apr 2006 22:23:26 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FWlIp-00067d-VI for qemu-devel@nongnu.org; Thu, 20 Apr 2006 22:23:24 -0400 Received: from [24.93.47.40] (helo=ms-smtp-01.texas.rr.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FWlKI-0003a2-8s for qemu-devel@nongnu.org; Thu, 20 Apr 2006 22:24:54 -0400 Received: from [192.168.0.11] (cpe-67-9-160-120.austin.res.rr.com [67.9.160.120]) by ms-smtp-01.texas.rr.com (8.13.4/8.13.4) with ESMTP id k3L2NKDH002409 for ; Thu, 20 Apr 2006 21:23:21 -0500 (CDT) Message-ID: <44484217.1030309@austin.rr.com> Date: Thu, 20 Apr 2006 21:23:19 -0500 From: Lonnie Mendez MIME-Version: 1.0 Subject: Re: [Qemu-devel] Large USB patch References: <4447E811.1040403@gmx.de> In-Reply-To: <4447E811.1040403@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: >With this patch applied I could detect a USB Epson Scanner and a USB >Epson Printer from Windows 98 + XP and I could even print pages with >the printer (see known problems below). > >reasons for this patch: >I was looking for a way to address my USB printer with windows while >working on linux. As I started the work I had to recognize that my >printer was not even detected under qemu. So I started to work on it. > > Are you sure such vast changes are necessary? What was it exactly that happened when you attached the printer/scanner? I'd be interested in seeing a packet log without all the changes that seem to "break stuff." >changes I made: >First I eliminated all potential error sources, which could be avoided. >One of these sources where the > >1. usb-hub - which I transfered to an extra file usb-hub.c, then I >added the usb-libusb.c devices directly to the UHCI controller this >introduced the changes of 2) >2. I enhanced the usb add device potentialities so that you should be >able to add a device to the UHCI controller. This device can be a usb >hub or a usb device. Behind this device you can add another hub or >device ... (remember this feature is now theoretically possible but not >tested yet), this let to a new usb syntax: >#$ qemu -usb controller=uhci,busnum=001 device=host:2:3,addto=001:001 >(the short form is: >#$ qemu -usb controller=uhci -usb device=host:2:3) >so you can build up a complete usb tree. >3. I changed the usb_generic_handle_packet() function and implemented a >state machine, which is able to handle the usb packets correct. >4. I changed the linux standard usb-host library to libusb. I personally >will always prefer a portable solution if possible. >5. I changed large parts of usb-libusb.c. Some changes were made because >I found the source very awkward, some others because I fixed errors and >some because I changed the general usb api (see item 2). >6. I tried to join as many usb functions as possible to the usb related >files. So that hopefully nobody has to change 15 files again. >7. I made minor changes to usb-uhci - mainly I applied the new api and >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. 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. Also keep in mind the people here probably don't know about the all-in-one patch on my webserver. I've never posted about it here except for on the user forums. >this patch breaks some things: >Sorry guys but I could not fix all of it, so I need your help, I didn't >want to destroy anybodys work, but the new api makes it necessary to >change some files: >1. usb-linux.c and usb-bsd.c will not work without adoption of the new api >2. I did not test usb-hid and usb-hub > > I'll try to look at the patch this weekend. >known problems: >1. under linux the uhci controller reports an error if no usb device is >connected >2. the printer and the scanner are recognized under Windows 98/XP and >Linux, but the scanner goes into STALL state as soon as a packet in >usb_write_bulk() or usb_read_bulk() >3. the libusb usb_host_reset() function does not work as expected and I >don't know why (i have commented out this part of the source) > > The reset function in libusb causes the device to have a new address when it reconnects therefore forcing you to rescan and open the device again. Perhaps this is the problem.