Hello Lonnie, First, thank you for the answer.
Lonnie Mendez wrote: > [EMAIL PROTECTED] wrote: > >> 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." 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). > >> 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. > 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. > 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: >> > I'll try to look at the patch this weekend. Thanks >> known problems: > 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. Yes I know this and I implemented it. But it does still not work. We get a STALL on the devices when the code is enabled. With kind regards Tino H. Seifert _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
