|
From: | Lonnie Mendez |
Subject: | Re: [Qemu-devel] Large USB patch |
Date: | Fri, 21 Apr 2006 02:04:36 -0500 |
User-agent: | Mozilla Thunderbird 1.0.7 (X11/20050923) |
address@hidden wrote: lo
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.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 commentsI'm in favor of a new api but with only one controller there isalmost 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.
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.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.
[Prev in Thread] | Current Thread | [Next in Thread] |